Release 6.6 - 2023 Feb

 

1.0 Campaign Manager module enhancements

1.1 'Campaign details’ screen enhancements

Based on user feedback, we have reduced the height of the ‘Campaign details’ card so that more space is freed up on the screen to display a few more rows of deployments within the campaign.

This enhancement is associated with the client-suggested Nolt enhancement idea #270.

1.2 ‘Deployments in this campaign’: Introduced the ‘Channel’ filter

Based on user feedback, we have added the single-select ‘Channel’ filter on the ‘Deployments in this campaign’ screen. The default value for this filter will be set to ‘All’ channels. You may select another channel from the dropdown.

This feature is associated with the client-suggested Nolt enhancement idea #264.

1.3 ‘Deployments in this campaign’: Introduced the ‘Deployment status’ filter

Based on user feedback, we have added the multi-select ‘Deployment status’ filter on the ‘Deployments in this campaign’ screen. By default, 8 status values will be pre-selected for this filer (i.e., ‘Completed by time’ and ‘Stopped’ status values are not selected by default).

If you override the default values for this filter, then the system will now ‘remember’ those filter values while you navigate back and forth between ‘Campaign list’, ‘Campaign details’ and ‘Deployment summary’ screens.

This feature is associated with the client-suggested Nolt enhancement ideas #243 and #287.

1.4 Easier way to create a new deployment based on an existing ‘Deployment template’

Now you will be able to create a new deployment based on an existing ‘Deployment template’ directly from the ‘Campaign details’ screen. Previously, you had to make 3 or 4 selections on the ‘Deployment creation wizard’ before you were able to leverage an existing deployment template. So, this feature could save you a lot of time – especially if you are a power user who creates a lot of deployments.

Usage notes:

1. On the ‘Campaign details’ screen, click on the new button called ‘Create deployment from template’.

2. A pop-up will then show listing all the deployment templates created by you (the logged-in user). You can also change the ‘Created by’ filter value if you want to use a deployment template created by someone else within your team. You can also use the other available filters for ‘Channel’ and ‘Schedule’ to narrow down the list of deployment templates on this pop-up.

3. Once you select the specific deployment template on this pop-up, you will be directly taken to the ‘Deployment canvas’ where you can make updates to the nodes as required and then save your new deployment with a new name.

1.5 Quickly view a deployment’s results on dashboard from the ‘Deployment list’ screen

We have a introduced a link to quickly access dashboard metrics from the ‘Deployments in this campaign’ screen for any specific deployment.

You will be able to access the ‘View on dashboard’ link from the 3-dot action menu for any deployment. When you click on this action, a new tab will be opened in your browser to display the deployment details information on dashboard.

If you click on the ‘View on dashboard’ action for another deployment, then another new browser tab will be opened to display the results of that deployment on the dashboard.
The dashboard tab will have two filters automatically applied:
• Deployment name: The deployment on which you clicked ‘View on dashboard’
• Date filter: A date range where ‘To date’ will be ‘today’ and ‘From date’ will be ‘deployment created date’. If the deployment was created more than 18 months ago, then the ‘From date’ will be 18 months.

This feature is not available for deployments which have the following statuses: ‘Draft’, ‘Rejected’ and ‘Sent for approval’.

1.6 Target data >> Test contacts: ‘Created by’ filter is now more easily accessible

As per user feedback, we have made the ‘Created by’ filter more easily accessible on the ‘Test contacts’ screen. Previously, you needed 4 extra clicks to access this filter. In addition, the default value of this filter has been changed to ‘All’ (rather than the previous value of ‘current logged in user’).

1.7 Target data >> Seed lists: ‘Created by’ filter is now more easily accessible

As per user feedback, we have made the ‘Created by’ filter more easily accessible on the ‘Seed lists’ screen. Previously, you needed 4 extra clicks to access this filter. In addition, the default value of this filter has been changed to ‘All’ (rather than the previous value of ‘current logged in user’).

1.8 Target data >> Target group splitter: ‘Created by’ filter is now more easily accessible

As per user feedback, we have made the ‘Created by’ filter more easily accessible on the ‘Target group splitter’ screen. Previously, you needed 4 extra clicks to access this filter. The default value of this filter has been set to ‘current logged in user’.

1.9 Target data >> Target group splitter: ‘TG splitter history’: UX improvements

We have made the following UX improvements on the ‘TG splitter history’ pop-up screen. Please note that this pop-up screen is only available and relevant for recurring TG split schedules i.e., it is not applicable for onetime TG split schedules.
a) The ‘TG split date and time’ column is now sorted in descending order because users are likely to be interested in looking at more recent TG splitter results. Previously, this column was sorted in ascending order of date and time, which means users were required to scroll down to the bottom of the table to see the latest results of the TG splitter.
b) We have added a date picker filter thus reducing the need for scrolling even further.
c) The lines separating each row of the table are now a bit darker – making it easier to visually distinguish each row and child-files generated during each run of the TG splitter.
This enhancement is associated with the user-requested Nolt enhancement # 291 and ServiceNow INC129900.

1.10 ‘Preview & test’: Send a test email / SMS / MMS: UX improvement

As per user feedback, when you select a test contact for sending a test message, the search textbox will be cleared – thus saving time before you add another test contact to the list.
This feature is associated with the client-suggested Nolt enhancement ideas #282.

1.11 Landing Pages: Configure links as ‘not-to-be-tracked’ using simple checkboxes

On the ‘Create landing page’ screen, you will now be able to configure links that you do not wish to be tracked by Webex Campaign. This new feature enhancement makes it much easier designate link for ‘non-tracking’ compared to the previous method of having to embed the tag ‘no-track’ in your HTML code for such links.

1.12 Assets >> Email partials: Configure links as ‘not-to-be-tracked’ using simple checkboxes

While creating email partials, you will now be able to configure links that you do not wish to be tracked by Webex Campaign. This new feature enhancement makes it much easier designate link for ‘non-tracking’ compared to the previous method of having to embed the tag ‘no-track’ in your HTML code for such links.

1.13 SMS deployments: UX improvements to the SMS content node

We have made the following UX improvements to the SMS content node:
a) Made the pop-up wider so that values within the dropdowns are easier to see.
b) The full values for the ‘Main URL’ and ‘Short URL’ are now visible. Previously, longer values of these URLs were cut-off with an ellipsis.
c) Removed the horizontal scrollbar from the links table.
d) Switched the position of the 2 buttons to improve accessibility of this screen for screen-reader users.
e) When the pop-up expander button is clicked in the top-left corner, the expanded pop-up now has the dropdowns even more wide so that values within the dropdowns are easier to see.

1.14 ‘Create Deployment’ wizard: new illustrations for deployment types

We have introduced new illustrations to easily indicate the deployment type while creating a new deployment

1.15 SMS & MMS: Message delivery based on recipients’ time zone (USA & Canada only)

We are very excited to introduce this feature for our clients in USA & Canada where your customers will be located across multiple timezones.

For SMS & MMS deployments, we have introduced a new toggle called ‘Send using local time zone of recipient’.
When this toggle is enabled for an SMS or MMS deployment, each recipient within the target group will receive the message at the specified time in their local timezone.

Previously, to achieve the same outcome, you would have to create a separate target group for each timezone (e.g., Eastern, Central, Mountain, Pacific etc.) and then associate that timezone with a corresponding deployment for that timezone.

With this feature, Webex Campaign will map the mobile number area code of each recipient in the target group to its respective time zone and will automatically create ‘sub-deployments’ corresponding to each timezone. Each of these sub-deployments will be automatically scheduled such that the contacts in its target group will receive the message at the scheduled time within their own timezone.

e.g., If the user who scheduled the deployment is located in New York and has scheduled the deployment for 9 am, then recipients in the Eastern time zone will receive the message at 9am Eastern; and recipients in the Pacific timezone will receive the messages 3 hours later at 9 am Pacific.

The main benefits of this feature are as follows:
• Your customers receive the message at the intended time in their own timezone – not too late and not too early.
• If SMS / MMS messages contain some call to action (e.g., a link to a website or an instruction to call into your contact center), then this feature may help prevent performance issues on a website or prevent the contact center being overwhelmed with calls coming from customers across the whole country.

Usage notes:

1. This feature is currently only available for clients who are hosted in AWS-USA and AWS-Canada.

2. In the USA, the following 6 timezones are supported:
   a. Eastern
   b. Central
   c. Mountain (Note: Although most parts of Arizona do not observe daylight saving time during the summer, any mobile number area codes in this state are mapped to the Mountain timezone. So, AZ recipients will be treated as if they are in the Mountain timezone all through the year).
   d. Pacific
   e. Alaska
   f. Hawaii

3. In Canada, the following 4 timezones are supported:
   a. Eastern (Note: Considering the smaller populations in the Atlantic & Newfoundland timezones, any mobile number area codes in those 2 timezones are mapped to the Eastern timezone. Therefore, on the UI, this timezone is called ‘AtlanticEastern’).
   b. Central (Note: Although Saskatchewan (SK) does not observe daylight saving time during the summer, any mobile number area codes in this province are mapped to the Central timezone. So, SK recipients will be treated as if they are in the Central timezone all through the year. Therefore, on the UI, this timezone is called ‘CentralSK’).
   c. Mountain
   d. Pacific

4. This is a tenant-specific feature; so, if you would like this feature to be enabled for your organization, then please contact your IMI/Cisco representative to get this switched on for you.

5. In this release 6.6, this feature is applicable to the following scenarios:
   a. Applicable channels: SMS & MMS
   b. One-time promotion-type deployments
   c. Recurring promotion-type deployments
   d. Target source types: File, SFTP and Existing TG
   e. Schedule nodes: Existing Calendar & New Calendar (i.e., not applicable for ‘Immediately’ node)
   f. Content type: Message (i.e., not applicable for File or API content types)

6. A new toggle called ‘Send using local time zone of recipient’ has been added in the schedule node to one-time and recurring promotion type deployments.

7. If the user selects this toggle option, then after the deployment is drafted, either 6 (for USA) or 4 (for Canada) sub-deployments will be automatically generated by the system corresponding to the timezones as mentioned above. The system will automatically split the originally attached target group by mapping the mobile number area codes to the respective timezones. Each sub-deployment will be named by adding 2 suffixes: a suffix in the format TZ1/TZ2/TZ3 etc. indicating the timezone sequence from the East to the West and another second suffix indicating the timezone (Eastern, Central, Mountain etc.). These ‘timezone aware sub-deployments’ can be easily identified by their prefix of the format ‘T x.y’.

Example – Canada timezone sub-deployments:

8. The ‘scheduled time’ for each of the sub-deployments becomes visible on the ‘Deployment list’ screen after the deployment is activated. This scheduled time is displayed in the timezone of the currently logged-in user.

9. As the sub-deployments in the Western timezones will be delivered one or more hours later than Eastern timezone, the system will validate the configuration to stop the user from scheduling a deployment too soon into the future (which will prevent it being sent to customers in the earlier Eastern timezones). The 2 examples below will clarify this restriction.

Example 1: If a marketer is based in the Pacific timezone, then for deployments which have this timezone feature enabled, the system will require that the deployment is activated at least 4 hours in advance of the intended scheduled time of message sending. This is to ensure that customers in the Eastern timezone can be sent the messages at the intended time in their local timezone.

Example 2: If a marketer is based in the Eastern timezone and tries to schedule a deployment to run 30 minutes from the current time, then the following error message will be displayed to them.

10. On the Deployment Summary screen, a new card has been added which shows the size of the split target group corresponding to each timezone.

Example – USA timezone sub-deployments’ target group counts.

1.16 Coming in an upcoming release: Limit on the maximum deployments within a campaign

This is an advance notice of a change we are planning to introduce in an upcoming release (either release 6.7 or release 6.8).

We are planning to introduce a limit on the maximum number of deployments that can be created within a single campaign. Initially, this limit is likely to be around 1,200 deployments within a single campaign.

Why are we proposing to introduce this limit on maximum deployments within a campaign?

In an upcoming release, we are planning to deliver a feature to enrich the information that is shown for each deployment on ‘Campaign details’ screen which shows the list of all the deployments within a campaign. e.g., we might show the Sender-ID, TG counts, TG names, next-send-date, P&L value, SMS message preview etc. for each deployment directly on this screen. Some of these values might be added as extra columns within the above grid table and some might be shown within a pop-up that shows when you hover the mouse over the deployment name in the 1st column.

This feature could save you a lot of time – especially if your role requires you to quickly review a lot of deployments created by others within your team as part of your quality-assurance processes. You will be able to view a lot more information about the deployments on the ‘Campaign detail’ screen itself, rather than having to click on each deployment name and check the ‘Deployment summary’ or ‘Deployment canvas’ screens.

However, as we increase the information density of this screen in the future, we want to ensure that this screen renders as quickly as possible within your browser. So, one way to achieve that is to apply a limit to the maximum number of deployments allowed within a campaign.

Further into the future, we also plan to introduce a feature to ‘archive a deployment’. This will enable you to ‘archive’ old deployments which may have been ‘completed’ or ‘stopped’ many months ago. Once archived, these old unneeded deployments will be removed from the ‘Campaign details’ screen. These ‘archived’ deployments will not count towards the limit mentioned above.

After this ‘deployment archival’ feature is available, we may further reduce the maximum number of deployments within a campaign to under 300.

How can you better prepare for this upcoming change?

If you currently have any campaigns with more than 250 deployments, then please consider not creating any more deployments within such campaigns. Instead, please create a new campaign and create your new deployments within that newly created campaign.

Finally, if you have any questions or concerns about these upcoming changes, then please let us know via your IMI/Cisco representative.

2.0 Email Composer & Landing Page Composer module enhancements

2.1 Email composer: ‘Partial’ block: UX improvement when selecting a ‘partial’

We have made it easier to select a ‘partial’ within the email composer. Now the partials are listed in alphabetical order, and you can now search for a specific partial. This feature is associated with the client-suggested Nolt enhancement idea #265.

2.2 Email composer: ‘Editable partial’ block: UX improvement when selecting an ‘editable partial’

We have made it easier to select an ‘editable partial’ within the email composer. Now the partials are listed in alphabetical order, and you can now search for a specific partial. This feature is associated with the client-suggested Nolt enhancement idea #265.

2.3 Landing page composer: Support for custom fonts for input field names

You can now configure your custom font for input field names within the Landing Page Composer. This enhancement is associated with the client-suggested Nolt idea #273.

2.4 Landing page composer: ‘Bold’ font option for ‘Submit’ button

You will now be able to specify the ‘bold’ font option for the ‘Submit button’ form element. This enhancement is associated with the client-suggested Nolt idea #274.

3.0 Dashboard & Reports module enhancements

3.1 Dashboard: Timezone-aware deployments (for USA & Canada only)

As mentioned previously in this release note, we have added the ability to deliver SMS & MMS deployment messages to recipients within their local timezone. Correspondingly, we have also added the same feature on the Dashboard. The ‘timezone-aware’ sub-deployments can be easily identified by their prefix of the format ‘Tx.y’.

3.2 Dashboard: Opt-out category now visible on ‘Deployment details’ screen for all channels

We have introduced a new field ‘Opt-out category’ on the dashboard ‘Deployment details’ screen. If there are multiple opt-out categories associated with a deployment, then these will be shown as comma separated values.

3.3 Dashboard: ‘Campaign list’ screen: removed ‘category’ column

A few months ago, we introduced an enhancement which allows the user to associate the opt-out category with a specific deployment (rather than having to associate it at a campaign-level). As users are now familiar with this change, we have removed the ‘category’ column from the ‘Campaign list’ screen.

3.4 Pre-configured reports: terminology updated to align with the new UI

As the old UI has now been decommissioned, the terminology associated with the old UI has now been updated in pre-configured reports as follows. This is applicable to both Summary reports and Transaction reports.
• Renamed ‘Comms (Onetime)’ to ‘Simple Promotion (Onetime)’
• Renamed ‘Comms (Recurring)’ to ‘Simple Promotion (Recurring)’
• Renamed ‘Follow up (InstantEvent)’ to ‘Instant (Event)’
• Renamed ‘Follow up (Onetime)’ to ‘Follow up Promotion (Onetime)’
• Renamed ‘Follow up (Recurring)’ to ‘Follow up Promotion (Recurring)’
• Renamed ‘Follow up (InstantMO)’ to ‘Instant (MO)’

Please note that in case of the following message processing statuses, the ‘gateway error code’ & ‘gateway error code description’ columns will not be populated: ‘Delivered’, ‘Sent (No Receipt)’ and ‘Not Pushed’.

3.5 Reports: Clarification note added about timezone of the schedule data shown in reports

The following explanatory note has been added to the screens where you configure Pre-configured reports, Scheduled reports, Download reports and Reports wizard:
“The reports always display the system timezone (which will not necessarily match with the tenant timezone). System timezone automatically adjusts according to daylight savings time (if daylight saving time is applicable in your region).”

3.6 Pre-configured reports: user permissions screen UX improvements

We have made a few small UX improvements in the ‘Administration >> Report permission’ screen to make it slightly easier to assign user roles to each specific report. The pop-up has been made slightly bigger and field labels are now more self-explanatory.
This enhancement is partially associated with the client-suggested Nolt idea #294.

3.7 Reports wizard: allowed characters in the custom report name.

We have updated the criteria for the report names in the 'Reports wizard'. You will be allowed to use the following characters within your custom report names: alphabets, numbers, spaces, underscores, and hyphens.

3.8 Dashboard: Getting ready for 8 new email engagement metrics in the next release (BETA)

In an upcoming release we are planning to introduce the following 8 additional email engagement metrics. These will be initially in BETA status.

1. Opens inferred from link clicks (Apple device)
2. % Opens inferred from link clicks (Apple device)
3. Opens inferred from link clicks (non-Apple device)
4. % Opens inferred from link clicks (non-Apple device)
5. Rejected opens due to Apple MPP bots.
6. % Rejected opens due to Apple MPP bots
7. Rejected opens due to non-Apple bots.
8. % Rejected opens due to non-Apple bots

In preparation for this feature in the next release, you will notice the placeholders for these 8 metrics on the dashboard within the ‘Engagement’ card for email deployments. These will currently show zero values. Please contact your Cisco/IMI representative to let them know whether you want these 8 new metrics displayed or not when they become fully available from the next release onwards.

Usage notes:

1. The existing 4 email engagement metrics remain unchanged in how they are calculated (i.e., unique opens, open rates, unique clicks and CTR).

2. The 8 new email engagement metrics will not be switched on by default for any client; if you are interested in getting these enabled, then please contact your Cisco / IMI account team.

3. The 8 new email engagement metrics will be available on the following 2 Dashboard screens:
   a. Campaign details (Email tab)
   b. Email deployment details

4. To support calculation of these future 8 new email engagement metrics, we have introduced within this release 6.6, some new ‘record-types’ in our RTE (Real-time EDR) database which keeps track of every delivery and engagement event for every customer to whom any message is sent from Webex Campaign on any channel. These new record-types are: 523, 524, 525, 526, 527, 528, 529 and 530.

If you currently receive a ‘raw’ data-feed from Webex Campaign’s RTE database, then you will notice records corresponding to the above new record-types in your data-feed after release 6.6 goes live.

On the other hand, if you receive a customized data-feed, then it will remain unchanged. If you want these new RTE records corresponding to the 8 new metrics to be included within your customized data-feed, then please contact your Cisco/IMI representative; they will need to arrange our professional services team to make this change to the algorithm that generates your custom data-feed.

Background context for the introduction of these new 8 email engagement metrics:
As you may recall, Apple introduced the MPP (Mail Privacy Protection) feature in iOS, iPadOS and MacOS in Sept – Oct 2021. For customers using the Apple Mail app and who opt-in for this MPP feature on their Apple devices (iPhones, iPads and Mac computers), Apple will first retrieve all their emails into its own proxy server. If and when the customer actually attempts to view their email, it will be served from Apple’s servers and not from the original sender.

While Apple’s intentions may have been good (i.e., to better protect the privacy of the customers of its devices), this MPP feature does have the following unintended consequences for email marketers:
• The ‘email open’ action cannot now reliably be tracked for Apple customers who opted into the MPP feature because the industry-standard method of tracking email opens relies on an invisible transparent pixel image which is served from the email sender’s servers. As Apple’s ‘MPP bots’ are now retrieving all emails for MPP-opted-in customers, it is now harder to decide whether and when such a customer actually opens their emails.
• If there is any logic in place to decide whether to send a ‘follow-up message’ based on tracking of the ‘previous-email-opened-or-not’ event, then this logic will now be less reliable for the subset of your customer base who may have opted into Apple’s MPP feature.

In the upcoming release, we will be adding the capability to ‘infer’ email opens if Webex Campaign detects that a link has been clicked within an email – even if it was not possible to reliably detect the email-open itself for a customer because they had opted into the Apple MPP feature.

This is represented by the first 4 new metrics listed above:
• Opens inferred from link clicks (Apple device)
• % Opens inferred from link clicks (Apple device)
• Opens inferred from link clicks (non-Apple device)
• % Opens inferred from link clicks (non-Apple device)

Even before Apple’s introduction of the MPP feature within its own ecosystem, there have been similar other bot-systems operational within other internet ecosystems; however, considering Apple’s large share of the devices market in the USA, Europe and many other regions, the Apple MPP feature has had more of an impact on email marketing ‘email opened’ metrics since its introduction in late 2021.

That’s why we had implemented many years ago the capability within Webex Campaign to filter out email opens that could reasonably be attributed to some type of ‘bot activity’. After Apple’s introduction of the MPP feature in late 2021, the email-opens that were attributed to Apple’s ‘MPP bot’, also automatically began to be filtered out within Webex Campaign’s email open metrics due to our already existing filtering algorithms.

With the introduction of these new email engagement metrics in the next release, we will be introducing more transparency in this already-existing filtering process.

This is represented by the last 4 metrics new metrics listed above:

• Rejected opens due to Apple MPP bots.
• % Rejected opens due to Apple MPP bots
• Rejected opens due to non-Apple bots.
• % Rejected opens due to non-Apple bots

4.0 Profile Manager module enhancements

4.1 Segment Builder >> Step 2 (Data sources): Primary-key column indicator added

Within the Segment Builder step 2, while specifying the relationship between multiple data sources, it is essential to know which column represents the unique identifier joining key in each of the data sources. Until now, you had to refer to the Profile Structure screen to find out about the primary key.

Now columns that are designated as ‘primary key’ within a data source are clearly indicated with a prefix of ‘(pk)’.

4.2 Segment Builder >> Step 2 (Data sources): Validation while selecting ‘CAMP_EDR’ datastore

Within the Segment Builder step 2, while selecting data sources, the CAMP_EDR data-source appears under 2 data-source-types: ‘Datastores’ and ‘Campaign data’. If you inadvertently select this ‘CAMP_EDR’ data-source twice, then, you will now be shown an alert prompting you to unselect the previously selected instance of ‘CAMP_EDR’.

4.3 Segment Builder >> Step 3 (Output headers): Use of ‘Aliases’ clearly indicated

Within the Segment Builder, for every output header for which an alias has been defined at the time of segment creation, you will be able to view the alias when you come back to view the segment later.

4.4 Segment Builder >> Step 4 (Filters): ‘Venn diagram’ icons restored

Within the Segment Builder step 4, based on user feedback, we have brought back the ‘Venn-diagram’ icons for the ‘Include’, ‘Exclude’ and ‘Filter’ operations when combining multiple filters.
This feature-change is associated with client suggested Nolt enhancement idea # 285.
Additionally, we have updated some labels to reflect the terminology being used on the new UI more consistently, e.g., the term ‘query’ has been replaced with ‘filter’ or ‘segment filter’.

4.5 Segment list: UX improvement while using ‘Copy segment definition to a dynamic TG’

Previously, one of the actions within the 3-dot action menu for each segment was called 'Copy segment to a dynamic TG'. From user feedback, we realized that this terminology was somewhat confusing because it gave the incorrect impression that the dynamic target group and its original source segment would be in sync. Some users also misunderstood that if they changed / deleted the original source segment, then correspondingly the derived dynamic target group would also be changed / deleted.

To clarify this 'one-off-derivation' behavior, we have renamed this action as 'Copy definition to a dynamic TG'. This better conveys that when you derive a 'Dynamic Target Group' from a 'Segment', you are only copying the 'Segment definition' (i.e., the combination of data sources, output headers and filters configured within that segment). The actual selected data records under that segment are not copied across to the dynamic target group. The dynamic target group created in this manner is an entity in its own right - it will re-execute the defined segment filters according to the schedule of the deployment to which the dynamic TG is attached. This dynamic TG will remain unaffected even if the original source segment is later amended or deleted.

4.6 Segment list: Validation added while using ‘Copy segment definition to a dynamic TG’

Previously, if a segment did not have any 'output header' that corresponds to a 'message destination' (e.g., MSISDN, EMAIL, APPDEVICEID etc.) and if you tried to create a dynamic target group from that segment, then the system did not give any feedback to the user that this is not possible because the segment does not have any appropriate 'message destination header'.
Now, we have added a validation and an alert message in this situation which clearly informs you what the problem is and what you can do to fix the issue. The user is given the suggestion to use the ‘Alias’ feature available on Segment Builder step 3.

4.7 Data Ingestion >> Datastores list: System-generated datastores are now displayed

You can now view the 'system-generated' datastores such as CAMP_EDR and CAMP_OPTOUT_DATA on the ‘Datastores list’ screen (Menu: Data management >> Data ingestion >> Datastores). As these are system-generated datastores, you cannot make any changes to them. So, the 3-dot action menu is not available for these datastores. However, you can now view the list of columns within these datastores more easily.

4.8 Profile definition: Improved UX while specifying profile attribute properties

Previously, you had to click on the 'settings' button next to each attribute to specify essential information about that attribute such as whether that attribute was to be designated as the primary key, whether to create an index on the attribute and whether to store it in encrypted format.

Now, you will be able to configure most of these attribute properties in the simple tabular view on the same screen - thus significantly reducing the number of clicks you need to configure a profile database.

4.9 Profile structures: Improved UX while viewing already created profile structures

The UX on the ‘Profile structures’ screen has been improved by displaying the most important profile attribute properties within the same screen. Previously, you had to click on the ‘settings’ button next to each attribute to view its properties. Some less frequently used properties are still to be found after clicking the ‘settings’ button.

5.0 Maintenance items in this release

The table below lists bug-fixes that are included in this release.