Capabilities rolling out in February 2023

Rules Screen

Rule Help

Templates already have links to help pages that explain where and how they should be used.

We’ve expanded this feature to Rules.

Rules can now have a help link added in settings, accessible from the file section of the toolbar. If a link is added the Rule now shows a link in two areas:

• In Rule Designer as a ? next to output links in the toolbar

Open

• In the Rules screen as a ? to the left of the Rule name in the list

  Open

  

Global Parameters

Ordered Lists

We now provide an option to choose an “Ordered List” data type in Global Parameters.

Add your parameter details as normal. Then choose Ordered List. You can now add the superset of values that may be included in your ordered list.

Open

Once these are set you can choose what order these values should be in in each target. You do not need to use each value in each target allowing you to only choose those that are needed.

Open

This functionality has been built to support the changes to our identification management within the GET CXID Public Template.

Rule Designer

Improvements to the toolbar

As we have added new functionality the toolbar in Rule Designer has grown in complexity. To make the Toolbar easier to navigate, it has been updated to show three key grouping of actions, to which functions have been added.

These groupings are:

• File

• Edit

• Tools

We have left on the ribbon bar the functions that either show valuable information on the makeup or state of the rule or where the function needs to be a single click away.

How to tell if your Rule has changed

With the previous toolbar the ‘save’ button would become active if the rule had been altered since the last save. To make this even more obvious we now also provide a “rule changed” indicator by adding an asterisk to the rule name when the Rule has been changed an not saved.

Open

Open versions of your Rule in the other targets

Alterian CX has been designed to allow the user to safely develop and test changes to Rules with no risk to the production system.

To do this we provide development, testing and production systems through a single solution. We call these separate systems targets.

Specific use of the Targets will depend on our customers development process but we would recommend the development of rules takes place in the development target. Once the rule is ready for testing it's copied into the test target. Depending on the changes taking place, the test target may be linked to a test system where the changes can be tested appropriately.

It’s likely that changes in one will need to be reviewed against another target before one is copied over the other. File now has a ‘Open Rule version in target’ function. Clicking on this will allow you to open the versions of this rule that currently exist in the other targets. You can then compare setup.

Tile Title split over two rows

The title of the title needs to convey a lot of descriptive information and therefore they can get long. To provide the greatest opportunity to provide a descriptive title we now allow the title to wrap over two rows.

Show Outputs to aid Rule Design

When reviewing a rule, it’s very useful to understand where in the Rule it has provided a response back to the calling system. This is useful in rule design.

Anything that happens after the rule has completed the decision making process will not affect the decision making process or slow it down.

We now show whether a Tile includes an Output (Realtime Output Step) in the Tile allowing rule designers to choose what actions occur before or after an output.

Open

Showing a Tile containing an Output

Decoding a Field within Rule Designer

Most rules are designed to be called by another system. In most cases the system passes in a JSON message which is read by a Tile and the values in the message and the fields they belong to are pulled out and passed into new fields in the flow of the rule.

Previously if the “message” being passed by the calling system needed to change to add new fields then the Realtime Input Tile and its JSON decoder needed to be opened in template builder and adapted to pull out the new fields.

To make this process easier we now allow this decoding to take place within rule designer.

Simply select the Output Connector from a Tile and then select “Create Decode from Field”.

You can then select the field to decode. In many cases “Message” will be the field to choose. Once the field is selected, add the names of the fields you want to “decode” from the field, choose a data type and if required you can rename the field being created.

Open

Decoding fields within Rule Designer

Setting Fields from Headers

Most rules are designed to be called by another system. The call contains a body that contains the bulk of the information the rule needs to work and optionally one or more headers.

In some cases the headers used in the call also contain useful information.

The fields created by the headers can now been seen in a Realtime inputs tab for tiles that contain a Realtime Input step.

Simply open the tile, click on Realtime Inputs and review the fields. Fields set in the underlying template cannot be removed.

New Headers can be added if needed by clicking on the plus button adding the field name required and choosing a data type. These can be removed again if needed.

Open

Cache Report

Superfluous client selection in Cache Report

Previously the first time you logged into the cache report, you were asked to select a client even if there is only one client avialable. We now only ask if more than one client is present.

Steps

CXID Processor

The CXID Processor has been updated to include the AlterianCX_identification Field parameter that can contain fields that provide identification of a user.

Public Templates

Get CXID now supports more efficient identification

We want to make it really easy to use Alterian CX. As part of this simplification process we wanted to reduce the number of Alterian specific fields we require a user to pass through when calling a rule.

Previously we have required “ChannelAgentID” fields to be passed through to identify an individual. Each ChannelAgentID field would actually contain a value that identified the individual. For example the ChannelAgentID1 field value could in fact be the “EmailAddress”. See examples below.

This process was inefficient. It made tagging harder as fields had to be renamed before they were passed through, and the field names themselves no longer reflected the value it contained. The user did not know that the ChannelAgentID1 field was in fact “EmailAddress”, so the Email Address was often passed through again as a separate field.

The Get CXID Public Template now has a new Parameter called AlterianCX_identificationFields.

Open

Showing the Values in AlterianCX_identificationFields

These parameter values allow the GET CXID to understand which fields flowing through it could be used to identify an individual and importantly which ones are more accurate indicators.

The best most accurate indicator is on the far left with accuracy decreasing as you move right. These values can be manually set or these can be simply set via an “Ordered list” Global Parameter.

The defaults provided in the parameter ensure we are backwards compatible with rules currently using the ChannelAgentID fields.

Realtime Input Configurable

Now we are not mandating that ChannelAgentIDs are passed through in our standard Rules we have created an example Tile that does not require the ChannelAgentID fields but does contain the other fields we create by default.

Validate Tracking Data removed

The validate Tracking Data Public template has been removed. It will be replaced in a future release with fuctionality built into the GET CXID template.

Journey Analytics

There are no Journey Analytics features in this release.

Fixes

Known Issues

Report Issue

To report an issue with the application not detailed here, please contact Technical Support. Please use our Service Desk to report issues.