TSA Connectivity Data Flows

Data flows between CXone applications, internal and external servers, contacts, and your tenant.

Information Flow Direction

The diagrams on the pages in this section represent external connectivity data flows. The arrows shown in these diagrams represent the flow of information. They do not represent where the information flow starts. Almost all flows go both ways, even though the connection may originate from one location. For example, most APIClosed APIs allow you to automate certain functionality by connecting your CXone system with other software your organization uses. flows are RESTful and always originate with the client. The information exchanged through the API can put information into and take information out of the CXone system. So, the arrow goes both ways.

Boundary Definition and Encryption

There are several types of boundaries represented in the diagrams on the pages in this section:

  • Primary Division: A line between public and private networks.
  • Edge Network: Suggest: A network not entirely public or private. The use of public cloud systems introduces this.
  • Layered Application: Related to public and private networks. They include public, DMZ, and internal areas.
  • Public Cloud Services: Can exist on the edge of public and DMZ or internal network environments.

Boundary devices or services may stop encryption at the edge of the public network on the primary division. In public clouds, this may also include edge networks. The diagrams show changes in encryption by changing the line style from solid to dashed. A solid line represents an area where data is encrypted. A dashed line represents an area where data is unencrypted. Depending on the cloud infrastructure, this may result in unencrypted traffic going over edge networks.

CXone Channels

CXone offers several different channelsClosed A way for contacts to interact with agents or bots. A channel can be voice, email, chat, social media, and so on. for tenants to interact with a business or contactClosed The person interacting with an agent, IVR, or bot in your contact center.. Channel transcripts, like native chat or voice, are not shared. Some user information is shared from NICE CXone to the Digital Experience channels.

Storage, when shown in the diagrams on the pages in this section, is either:

In the diagrams, Cloud Storage uses tenant-specific keys. Storage does not.

In almost all cases, a message broker is being utilized. They are not shown in the diagrams and don't transfer sensitive information.

Support for transcript encryption of sensitive data varies based on the channel used:

  • ACD Channels

    • Phone: supported.

    • Chat: supported.

    • Classic Email: supported.

    • Cloud Email: supported.

    • SMS: supported.

    • Voicemail: supported.

    • Work Item: supported.

    • Callback: supported.

    • Personal Connection, Phone: supported.

    • Advanced Chat/Co-Browse: not supported.

  • Digital Experience Channels

    • Phone: supported.

    • Chat: supported.

    • Classic Email: supported.

    • Cloud Email: not supported.

    • SMS: not supported.

    • Voicemail: not supported.

    • Work Item: not supported.

    • Callback: not supported.

    • Personal Connection, Phone: not supported.

    • Advanced Chat/Co-Browse: not supported.

General CXone Components

The diagram below shows general CXone service components and their relationships. The CXone Cloud:

  • Encompasses the entire CXone infrastructure for production systems.

  • Equally represents the FedRAMP and non-FedRAMP systems.

  • Is divided into two main components: the application infrastructure and the voice infrastructure.

The application infrastructure could live in the private or public cloud infrastructure depending on the original implementation. The voice infrastructure is almost exclusively provided through private cloud infrastructure. This is due to the performance requirements of voice equipment.

Also shown are a variety of different external networks, including:

  • NICE CXone corporate systems.

  • Partner services.

  • External networks.

  • External services.

These are used to provide core functionality and tenant-facing production networks.

The connectivity shown in the diagram represents aggregated information. In all cases, both personal and non-personal information may be transmitted. CXone does not analyze tenant or contact data to classify it into data types. So, CXone manages all data as sensitive at the highest levels. The non-encrypted traffic shown is almost always related to traffic from channelsClosed A way for contacts to interact with agents or bots. A channel can be voice, email, chat, social media, and so on.. This internal data is mostly carried over channels governed by TLS ciphers. Some internal hops may not have TLS configuration. Internal data is not said to be encrypted in every case.

This communication is shown in more detail in the diagrams on other pages in this section.

Diagram of general CXone component data flow.

Common Product Flows

Most flows between users and the CXone Cloud occur between a web browser and the application infrastructure. These flows use standard web protocols utilizing TLS algorithms. This communication applies to all products that list port 443 with the destination of the application infrastructure. Port 80 may also be listed. Many of these applications use other services of the environment, but there are three basic targets:

These targets are all technically web servers, but their functions and endpoints (hostnames) are distinct. The endpoints live in a demilitarized zone (DMZ) and use a standard-tiered application model.

The diagram below covers the following applications:

  • Auto Attendant.

  • Central (except SFTP).

  • Direct Data Access.

As shown in the diagram below, API and web server communication may contain personal information. Authentication flows may contain personal data in the token responses.

A diagram that shows how users connect with different server types through our application infrastructure.