Historical Changes in Data

Data gets updated over time — queues get renamed, organization hierarchy changes, people move from team to team, etc. Salted CX tries to best represent history in a way that is accurate and provides expected data. However, data sources may impact our ability to do so. This article covers technical details of how historical data look in Salted CX.

Entities

Salted CX uses entities to represent important objects in a contact center world. These entities represent many different concepts such as teams, queues, agent statuses, etc. These entities have a permanent identifier (PID), an external identifier (ID they have in the data source), and a human-readable name.

Salted CX uses permanent immutable identifiers (PIDs) to reference entities from data sets. These PIDs are not updated after an entity is created and ensure the integrity of the data. Entity names are used for visualization in our application including customer journey, reporting, etc.

There are two ways how PIDs are generated:

• Based on immutable external ID. Preferred method if the stable ID is available in the given platform. This enables renaming entities without breaking references.
• Based on name or mutable ID. This is a fallback method if the platform does not have immutable IDs for the given entity type.

The below table shows the comparison of these representations and how they

Property	Past	Present
Entity with Data Source ID
PID	3b7b04f3-aee1-44e1-96a9-3b85604c770e	3b7b04f3-aee1-44e1-96a9-3b85604c770e
External ID	data-source-immutable-id	data-source-immutable-id
Name	Original Name	New Name
Entity without Data Source ID
PID	6bfda030-ad65-478a-ac9f-bde605a13776	4f6ac436-80b8-46a7-9244-7994a00fd455
External ID	Original Name	New Name
Name	Original Name	New Name

PIDs Based on Entity External ID

Salted CX uses data source IDs by default to have stable references even when the entity gets renamed in the original data source. This enables maintaining referential integrity even when the entity gets renamed.

Salted CX always shows the latest name for the entity. For example, if a team gets renamed even past engagements will show the latest name of the team. If you want to break this relationship you have to create a new team in the data source and associate agents with that team. This applies to every entity including but not limited.

note

Be careful when working with these entities. Renaming the entity does not change its purpose historically. Do not repurpose these entities for different use cases that you do not want to see in reporting together. Always delete or deactivate the old entities and create new ones.

PIDs Based on Entity Name

In case the data source does not have IDs for the given entity name Salted CX generates PIDs based on the entity name. This is a fallback scenario and Salted CX uses it only if there is no support for stable ID for the given entity.

Before creating a name-based PID for an entity, Salted CX does the following operations:

• Trims leading and trailing spaces
• Converts the name to the lower case

The below example demonstrates the issue on a chart that shows volume of engagements in two queues. In the scenario the blue Queue was renamed to the green Queue - Renamed in the middle of the month. This leads to a major issue when calculating some metrics as part of the engagements is attributed to one queue and the rest to the other queue. Which leads to misleading numbers in charts and tables.

Engagements Count	April	May	June	July	August	September
Queue	17	26	31	15	—	—
Queue - Renamed	—	—	—	20	37	36
Another Queue	20	24	26	27	28	28

note

Be careful when renaming entities in the original platform that do not have stable IDs. Renaming entities that do not have stable ID in the original platform will lead to breaking the continuity of data and potentially lead to misleading metric numbers — especially when reporting on volumes segmented by the entity type that got renamed.

Deleted Objects

In many platforms you can delete objects that Salted CX imports. How deleted objects look like in Salted CX depends on the circumstances of the delete:

• The object is “soft-deleted” in the source platform — Salted CX imports the object including all its available attributes. If the object is translated to a data set stat has Status attribute, the Status attribute is set to value Deleted.
• The object is deleted but Salted CX imported it in the past — Salted CX keeps all references to the object and its attributes. If the object is translated to a data set stat has Status attribute, the Status attribute is set to value Deleted.
• The object is deleted before it was imported into Salted CX but other objects still reference it by its original ID — Salted CX created a placeholder for the object that does not have any other attribute than its ID in the source platform. Salted CX then uses name ∅ <platform ID> to indicate that the object was deleted and also keep distinguishable names for the deleted objects.
• The object is deleted and references to it are removed — Salted CX is not aware of what objects are originally referenced and uses reference to empty entity.

note

We strongly recommend to perform so-called “soft delete” if your platform supports it. Soft delete does not delete the entity but marks it as deleted. This enables to preserve the historical data and excludes the entity from usage in your platform. For example a soft deleted queue no longer accepts any conversations from customers but the group name is still available in historical reporting so you see how many conversations the queue received in the past.

Before and After Salted CX

Salted CX data may provide a different level of detail depending on when a data source was connected to Salted CX.

note

Our recommendation is to connect the data source to Salted CX as soon as possible even when users do not have yet access to Salted CX. This approach enables to gathering deeper history time history with full set of supported features.

note

Always exercise additional caution when acting on data before Salted CX was connected. We recommend to review our documentation for the given data source in case the metrics before connecting Salted CX significantly differs from metrics after connecting Salted CX.

After Salted CX

Salted CX primary focus is to provide the most value from the moment you connect the data source. Because of this Salted CX tries to use the most granular method for retrieving the data even when it is not available for conversations that happened in the past. This may lead to some differences between data discussed in the next section.

Before Salted CX

Depending on the data source availability of data may be limited due to the connected data source features, architecture, limitations, and configuration. The exact impact on data depends on the mentioned factors.

The focus when loading the historical data is:

• Have the same way of calculating metrics and attributes. Salted CX tries to have no or minimal differences in how data are represented in both time frames.
• Provide as much facts and attributes as possible. Historical data may not contain the same level of granularity.

There are certain issues we have identified in different data sources in the table below.

Issue	Description and Mitigation
No data available	Some data sources may keep data only for a limited time. After that time they provide no data or the data are not granular enough to convert them to the Salted CX Logical Model. This might be for example when the data are available only in an aggregated form via a historical API. There is typically no workaround unless the customer has backup data. In such cases, they can use Ingest API to load the historical data.
Less attributes	Some data sources may contain less information in permanent storage than they produce on the fly. Some data sources enable to consumption stream of very granular events that provide very detailed information about any update in the data source. However, these events are stored only for a limited time and after that, they are deleted from the data source. Only less detailed data are available permanently in the data source.
State transitions are not available	Conversations may go through state transitions during multiple engagements in the conversation. This would typically be reflected in engagement attributes such as Reason, Outcome, etc. Some data sources only contain information about the last state of the conversation (or a corresponding entity in the source system). This may manifest itself by having less granularity in the past data and missing visibility into how agents progressed when working on conversation especially if there were more agents involved. This may also lead to missing queue engagements, invitation engagements, and other transitions in the customer journey.
Engagement and other activity attribution issues	Most data sources contain only information on who is the agent that handled an engagement but do not contain details about the organization hierarchy (team in which the agent was) when the agent handed that engagement. They only contain information about the current organization structure. When agents are moving in the company organization hierarchy or the structure itself changes the teams, departments, locations, and other organization units in which agents are now may be different from the organization units in which agents were when the engagement happened. This leads to potentially skewing metrics based on engagements and activities before connecting to Salted CX. When working with trends and other metrics over a longer time scale make sure then when interpreting metrics you consider the possibility of agents moving around.