Network Diagrams

Network diagrams illustrate how information flows across CXone applications. The arrows in the diagrams represent the flow of information and not the source of the request. Almost all of the flows appear bi-directional, even though the connection may always originate from one location. For example, most API flows are RESTful and always originate with the client. However, data passed through the API may be put into the system, extracted from the system or both. That's why the arrow is shown as bi-directional.

There are several types of divisions, or boundaries, in the diagrams. A primary boundary is between public and private networks. Private networks may include another boundary between internal and DMZ networks. The DMZ provides a way to interact with public networks while protecting sensitive internal networks.

Public cloud systems introduce a combined network which is not entirely public or private. This is referred to as an edge network, since boundary devices and services usually terminate encryption at the edge of the public network.

The diagrams indicate changes in encryption by solid and dashed lines. Depending on the cloud infrastructure, this may result in unencrypted traffic going over edge networks.

Unless otherwise stated, all customer data is encrypted in transit and at rest.

Field

Details
Private cloud, corporate, or customer premise locations

Public and private cloud locations
Internal segmentation within public or private cloud locations
Individuals that use the services
Applications and services that use the services
User devices
Encrypted, non-personal information flows, with arrows indicating direction
Non-encrypted, non-personal information flows, with arrows indicating direction
Encrypted personal information flows, with arrows indicating direction
Non-encrypted, personal information flows, with arrows indicating direction
Hybrid flows for personal or non-personal information, where a boundary device terminates encryption

High-Level Components

Diagram of high-level components.

This diagram shows high-level components of CXone and their relationships with one another. The CXone Cloud container encompasses all CXone infrastructure for both FedRAMP and non-FedRAMP production systems. CXone is hosted in both private and public clouds, and is divided into application infrastructure and voice infrastructure. Voice Infrastructure is hosted almost exclusively through the private cloud.

The containers on the left side are external networks and are essential for product functionality. These external services include:

  • NICE CXone
  • Partners
  • External Services
  • Tenant

In all cases, both personal and non-personal information is being transmitted. Non-encrypted traffic is almost always related to voice or other channelClosed A way for contacts to interact with agents or bots. A channel can be voice, email, chat, social media, and so on. traffic and may not be fully encrypted.

Common Flows

Diagram of common product flows.

This diagram illustrates how users interact with CXone using the application infrastructure and the following applications:

  • Auto Attendant
  • CXone web portal apps like ACD, Admin, and so on (except FTP)
  • Direct Data Access

Most user interactions occur between a browser and the application infrastructure using standard web protocols and ports (443 and 80). Some CXone suite applications require other services and additional portsClosed Where information transfers, over a network, between a computer and a server. from your environment must be opened. There are three basic services shown in the application infrastructure container:

Each of these are technically web servers but their functions and endpoints are distinct. All endpoints live in a DMZ using a standard tiered-application model. API and web server communication may contain personal information. Authentication flows may contain personal data in token responses.

External Service Integrations

Diagram of external service integrations.

Partners and other providers can create applications that integrate with CXone. This diagram illustrates how users interact with Performance Management using the application infrastructure and external integrations. Partner and external services components are combined to simplify the diagram, but the service could be provided by either.

Partner integrations can include their own authentication or they may integrate through various menus. They will always open in a separate browser instance and integrate through various APIsClosed APIs allow you to automate certain functionality by connecting your CXone system with other software your organization uses.. In very few cases, an integration may consume content from CXone web servers. Customer chat interface is an example of this.

IVR Integrations

Diagram of IVR integrations.

This diagram illustrates how IVRClosed Automated phone menu that allows callers to interact through voice commands, key inputs, or both, to obtain information, route an inbound voice call, or both. interacts with tenants and external services. IVR often incorporates data from external sources which may be managed by you or by a third party. In these cases, the traffic always originates from internal servers.

Agent Connectivity

Agents can interact with CXone using several different methods:

These options can use either a physical phone or softphone.

MAX

Diagram of max integrations.

This diagram illustrates agent connectivity for MAX using a physical phone or softphone. MAX integrates with the application infrastructure. The phone primarily interfaces with the voice infrastructure. There is also some application communication and, for softphones, a dependence on external service integrations.

Salesforce Agent and Agent for Oracle Service Cloud

Diagram of Salesforce Agent and Agent for Oracle Service Cloud integrations.

This diagram illustrates agent connectivity for Salesforce Agent and Agent for Oracle Service Cloud using a physical phone or softphone. These phones are excluded from the diagram for simplicity.

Both agent applications depend on external service resources. However, they also communicate directly with the application infrastructure and are part of the CXone product suite. In some cases, the products may communicate with the authentication server to provide authentication and interact with endpoints.

Channel Connectivity

The following diagrams illustrate the data flow of sensitive information.

Voice Channel

Diagram of voice infrastructure.
Diagram of physical voice infrastructure.

These diagrams illustrate customer-leg voice connectivity within CXone. Redundancy and failover are critical features for voice infrastructure.

Connectivity from the source to a Session Border Controller (SBC) in the voice infrastructure is not shown for simplicity. This connectivity may be a series of links involving a variety of carriers. All of this traffic ends at the SBC in the CXone environment. It is at the SBC that agent-leg connectivity is established.

This information is managed and monitored by the CXone orchestration engine and media server, which can record the conversation. In both instances of recording, CXone has the ability to mask or pause recording if sensitive information is being communicated.

Recordings made by the media server can either pass directly to the file server or they can pass through a compression server. Recordings made by the media server reside in file server storage or Cloud Storage Services.

Real-time voice is not encrypted in transit to the server. Once it is stored on either the media server or the CXone Recording server, it is encrypted at rest and in transit.

Email

Learn more about email networking requirements on the System Email page.

Diagram of inbound email connectivity.

This diagram illustrates inbound email connectivity. Inbound email uses either AWS SES or private cloud email servers. Emails are sent to the storage service where the CXone orchestration engine handles notifications and APIClosed APIs allow you to automate certain functionality by connecting your CXone system with other software your organization uses. access to applications.

In most cases, emails are forwarded to the platform from your SMTP server because the inbound email addresses are owned and managed by your organization.

Diagram of inbound email connectivity.

This diagram illustrates outbound email connectivity. Depending on your requirements, outbound email channels can come:

  • From your SMTP server through a private connection.
  • Through SES (preferred) or private cloud SMTP servers.

Historical information is stored in an Amazon S3 bucket.

Chat

Diagram of chat connectivity.

This diagram illustrates omnichannel chat connectivity. Chat is managed through a combination of the business unitClosed High-level organizational grouping used to manage technical support, billing, and global settings for your CXone environment web server, CXone web server, and a series of authentication and API calls that store transcripts. These transcripts can then be moved into Amazon S3 and Amazon Glacier.

Digital Experience: Social and Bring Your Own Channel (BYOC)

Network diagram of interactions that take place on digital channels, such as social media.

This diagram illustrates connectivity for social media channels and Bring Your Own Channel (BYOC) integrations. For social media channels, interactions are brokered by the various channel providers, such as Facebook or Google. BYOC is an option where your organization can build and host middleware services to sit between the CXone APIs and the third-party channel APIs. The middleware relays messages between the CXone platform and the third-party channel provider.

Contacts only interface with the third-party channel providers. The agent interfaces with CXone over a set of web, authentication, and API servers. The connection between the contact and the agent is managed by a series of channel connectors and internal eventing systems. Temporary and permanent storage is managed internally.

Digital Experience: CXone Email

Network diagram of interactions that take place on digital email channels.

This is a diagram of digital email connectivity.

Digital Experience: Digital Chat

Network diagram of interactions that take place on digital chat channels.

This is a diagram of digital chat connectivity. Contacts communicate with digital Live Chat or Chat Messaging using a digital chat window, which can be web- or mobile-based. Digital chat communicates primarily through WebSocket connections handled by the AWS API Gateway. Agents communicate using a browser-based agent application that connects to the CXone platform via a public REST API to work on incoming contacts. Communication goes in both directions in real time: 

  • Initiated by the contact: The WebSocket server communicates with the digital chat connector that handles custom chat logic and stores data within the CXone platform.
  • Initiated by the agent: The event is propagated from the CXone platform through the chat connector to the WebSocket server, and then to the contact.

In the diagram, the following services are represented: 

  • Consumer (Client) interface: The digital chat window, either mobile or web. It connects to the WebSocket server for real-time communication.
  • Agent interface: The agent's browser connects to the general CXone platform via a public REST API to work on incoming contacts.
  • Chat WebSocket server: The WebSocket server mediates real-time communication between the general CXone platform and the digital chat consumer.
  • Chat connector: The WebSocket service that translates the specific chat domain into the general CXone domain.
  • Application infrastructure: The rest of the CXone services and automations that handle digital contacts.

IEX WFM Integrated Connectivity

IEX WFM Integrated Network Diagram

This diagram illustrates basic connectivity between your environment and IEX WFM Integrated.

Engage QM Integrated Connectivity

Diagram of chat connectivity.

This diagram illustrates basic connectivity between your environment and Engage QM Integrated. Other architectures are also supported.

Connectivity by Hostname

CXone uses a variety of different hostnames and services depending on the type of connectivity:

Private Data Center Connectivity

Diagram of private data center connectivity.

(1) Traffic from the external network ends at a hardware firewall, which terminates the TLS session. Secure traffic uses TLS 1.2 or greater. Unsecured traffic is handled by the server. (2) Traffic between the firewall and server is not encrypted.

The following areas refer to private data centers:

  • US Data Center
  • EU Data Center

This diagram illustrates private data center connectivity with the following hostnames:

Hostnames
agent-{cluster}
agentstats-{cluster}
api-{cluster}
api
bi
bu{tenant}
engage
getnextevent-{cluster}
home-{cluster}
incontrol-{cluster}
intouch-{cluster}
login
phonebook-{cluster}
reporter.engage
screen{num}
search
security
stream{num}
{cluster}
{custom}

Direct AWS Data Center Connectivity

Diagram of direct AWS data center connectivity.

(1) Traffic from the external network ends at an application load balancer, which terminates the TLS session. Secure traffic uses TLS 1.2 or greater. Unsecured traffic is handled by the server. (2) Traffic between the firewall and server is not encrypted.

The following areas refer to direct data centers:

  • US AWS
  • FedRAMP AWS
  • EU AWS
  • AUS AWS

The diagram illustrates direct AWS data center connectivity with the following hostnames:

Hostnames
agent-{cluster}
agentstats-{cluster}
analytics-{area}
analytics
api-{area}
api-{cluster}
api
auth
bi-{area}
bu{tenant}-nicewfm
echo-{area}
echoftp-{area}
getnextevent-{cluster}
home-{cluster}
incontact
incontrol-{cluster}
intouch-{cluster}
login-{area}
login
phonebook-{cluster}
security-{area}
security
{cluster}
{custom}

Indirect AWS Data Center Connectivity

Diagram of indirect AWS data center connectivity.

(1) Traffic from the external network ends at an Incapsula service, which terminates the TLS session. (2) Traffic between the Incapsula service, which starts a new TLS session, and the application load balancer, which terminates the TLS session. Secure traffic uses TLS 1.2 or greater. Unsecured traffic is handled by the server. (3) Traffic between the application load balancer and proxy is not encrypted. Traffic between the proxy and the server is not encrypted.

The following areas refer to public data centers:

  • US AWS
  • FedRAMP AWS
  • EU AWS
  • AUS AWS

The diagram illustrates indirect AWS data center connectivity with the following hostnames:

Hostnames
{area}

Nexidia

Diagram of CXone and the LPL DataLake connecting to Nexidia.

This diagram illustrates how CXone connects to Nexidia. This connection is established through the use of these APIs:

These APIs pull recordings and metadata from CXone.

Nexidia Data Flow

Diagram of APIs extracting recordings and metadata from CXone and connecting to Nexidia.

(1) APIs extract metadata and audio recordings from CXone. (2) The metadata is cataloged and the recordings are processed in the Data Exchange Framework (DEF). (3) Processed data from the DEF is copied to Media Storage. (4) In Media Storage, the data is phonetically indexed. (5) Still in Media Storage, the data is transcribed and phrases are extracted. (6) Analysts use the Nexidia application to listen to calls, view transcriptions, and build queries and reports.

This diagram illustrates how recordings and metadata from CXone are pulled into Nexidia servers for analysts to listen to and view.