/
How to validate your data through the GET CXID

How to validate your data through the GET CXID

We need to ensure events being pushed into Journey Analytics and the CX Dashboards are accurate and will create useful learnings for our users. We do not validate the data that is fed into Rules, relying instead on our customers to be careful when building rules and integrating to ensure the required fields are available when needed.

Our Journey Analytics and the CX Dashboards have mandatory fields and work best when the data provided meets our field and format requirements.

The GET CXID public template can be set to check for the existence of these mandatory fields, check the format of these fields is correct and provide a way to output rows that fail validation.

The GET CXID does not itself remove rows that fail validation. Instead it will highlight the row as failing validation then it will skip the queues present in the CXID Template, but still allow the row to flow through the step allowing our users a choice on how to handle these exceptions. We would recommend a that these invalid rows are removed with a Invalid Data S3 Output step before they flow through to any other queues.

In the future our Event Queue Public templates will be configured to no longer accept failing rows. Users should use this Template to understand where validation failings are occuring and make the necassary changes to the Rule or integration to correct.

 

Validate tracking data in the GET CXID

Turning on validation

To turn on tracking data validation in the GET CXID open parameters and change the parameter AlterianCX_validateTrackingData from N the default to Y.

 

Switch

Description

Example

Switch

Description

Example

AlterianCX_validateTrackingData

Turns on validation of tracking data in the GET CXID

Y - Validation is on

N (Default) - Validation is off

 

Input values

Field

Description

Example

Field

Description

Example

AlterianCX_isvalid

Added by the RIS or the PFE steps for use by this Template. If the Invocation fails validation this template will change the field value here to N or Y

AlterianCX_isvalid = null - Row has not yet been through Validation

AlterianCX_isvalid = N - Row has failed Validation

AlterianCX_isvalid = Y - Row has passed Validation

 

Identifier

At least one identifier should should be present*

Phone Number

AlterianCX_isknown

Required for validation. A none null value needs to exist

 

AlterianQueue_location

Required for validation. A none null value needs to exist

 

AlterianQueue_channel

Required for validation. A none null value needs to exist

 

 

Processing

The template will validate the fields and formats shown above. If the row fails validation the “AlterianCX_isvalid =” field is updated to AlterianCX_isvalid =N if it passes validation the field is updated to AlterianCX_isvalid = Y.

This field is created by the Realtime Input Step and the PFE steps and before it passes through the GET CXID it will simply be null and show as AlterianCX_isvalid =null in the logs.

Please note it’s possible in the future more than one type of data validation will be supported. If more than one is used it may be the row passes validation for one and not the other. We would still class thta row as failing validation.

Rows failing validation can be reviewed in the logs or they can be exported for further investigations using the Invalid Data S3 Output public template.

 

Choosing to ignore invlaid data

Various Alterian templates provide a way to stop the template activating if the data flowing into it is not valid. For example the step below belongs to the Email Manager step and we can set it to not send emails if the data in the flow of the rule is not seen as valid.

Users are able to choose from three settings

Option

Action

Option

Action

Write only… if Data is valid

Will only action the step - i.e send emails if the row is marked as valid

Write only… if Data is not valid

Will NOT action the step - i.e send emails because the row is marked as invalid

Always Write

Will ignore the validation flag and always action. this provides alight performance improvements and backwards compatability

image-20240221-131948.png
EmailManager step showing validation logic

Note: It’s possible to use a parameter to hard code the “write only if logic”. Create the Parameter and pass it through with valid, invalid, always. The value is not case sensitive.

Related content