Release 7.0 - 2024 July
1.0 Campaign Manager module enhancements
1.1 SMS promotion deployments: use a ‘contact policy allow list’ as a target group source
This is a tenant-specific feature; it is useful for those clients:
a) who use both Webex Campaign and Webex Connect for their various marketing and non-marketing use cases and
b) who use the optional module within Webex Connect called ‘Contact Policy’ to store and manage their customers’ opt-in and opt-out preferences for receiving communications via specific channels.
In this release, we have introduced integration of Webex Campaign with this ‘Contact Policy’ module for the following specific use case: You can now use a ‘Contact Policy Allow List’ as a Target Group Source while configuring an SMS promotion deployment. This feature is associated with the client-requested enhancement Nolt #351.
This feature is currently only available:
a) for SMS channel ‘simple promotion’ type deployments and
b) for clients who use Webex Connect as their SMS channel gateway.
Pre-requisites for using this feature:
a) You will need to have a valid tenant on Webex Connect.
b) You will need to have enabled the usage of the optional ‘Contact Policy’ module within your Webex Connect tenant.
c) You will need to have created at least one ‘Consent Group’ with a Group Category of ‘Allow List’. This ‘Allow List’ will have the mobile numbers (MSISDNs) of your customers who have opted in to receive communications from you via the SMS channel. Within ‘Contact Policy’, SMS channel is referred to as ‘Text’ channel.
d) You will need to request the Webex CPaaS Tech Support team to associate your Webex Campaign tenant with the corresponding Webex Connect tenant.
e) As this is a tenant-specific feature, you will need to request the Webex CPaaS Tech Support team to enable the ‘Contact Policy Integration’ feature on the Webex Campaign Admin Console.
How ‘Contact Policy Allow Lists’ data will be available to use within Webex Campaign:
a) As part of this integration with the ‘Contact Policy’ module, every morning once a day at approximately 5 am system time, Webex Campaign will automatically retrieve all the SMS opt-in records from all the ‘Allow Lists’ from your Webex Connect tenant’s Contact Policy module.
b) Only the ‘Allow Lists’ will be retrieved into Webex Campaign. i.e. ‘Deny Lists’ will not be retrieved.
c) Only those records from ‘Allow Lists’ will be retrieved into Webex Campaign which match the following criteria: ‘Channel’ = ‘text’ and ‘Consent’ = ‘true’.
d) These ‘Allow Lists’ will be fully flushed and reloaded every morning.
e) If an ‘Allow List’ has been disabled in the ‘Contact Policy’ module during the day (after it has been retrieved into Webex Campaign at 5 am), then during next morning’s refresh, this ‘Allow List’ will not be retrieved into Webex Campaign.
f). We have introduced a new screen to display the information about the ‘Contact policy groups’ which have been retrieved from your Webex Connect Contact Policy module. This screen is available here: Campaigns >> Target data >> Contact policy groups.
g) Any user whose role has the permission to view the ‘Target groups’ screen will also be able to view this new ‘Contact policy groups’ screen.
h) As these ‘Contact policy groups’ are system-created, they will always be visible to eligible users irrespective of which ‘User Group’ the user is currently in.
i) The ‘Last updated’ column in the above screen will show the date and time each ‘Allow List’ was refreshed within Webex Campaign. In production environments, the timestamp should be between 5 am and 5:30 am on each day.
j) The following 10 header values for each opt-in consent record will be retrieved from ‘Contact Policy’ into Webex Campaign:
i. MSISDN (while importing into Webex Campaign, the leading ‘+’ sign will be removed)
ii. CHANNEL (this value will always be ‘text’)
iii. GROUPID
iv. CONSENT (this value will always be ‘true’)
v. EXPIRES (this is the date/time when the customer’s opt-in consent expires)
vi. LASTUPDATED (this is when the opt-in record within ‘Contact Policy’ was last updated)
vii. REASON
viii. KEYWORD
ix. CAMPAIGN (this is different from what a ‘Campaign’ means in Webex Campaign)
x. SOURCE
k) This means if you use a ‘Contact policy group’ as a ‘TG Source’ within a deployment, then only these 10 headers can be used for personalization and conditional content logic.
How to use this feature (i.e. use a ‘Contact Policy Allow List’ as a Target Group Source while configuring an SMS promotion deployment):
a) When creating an SMS Promotion deployment, on the left side of the deployment canvas, you will now see a new node for ‘Contact policy group’ as a Target Group Source. You will need to drag and drop this node on to the blank Target group placeholder in the central canvas.
b) Next, you will need to click on the ‘Add’ link on the right-side node properties panel to select one of the allow lists. These allow lists would have been retrieved in the morning into Webex Campaign from your Webex Connect Contact Policy module.
c) Next, you will need to save the ‘Contact policy group’ node. Next, you will need to configure the schedule and SMS content nodes as usual; then save the deployment and activate it as usual.
d) As mentioned above, the ‘Allow lists’ are retrieved into Webex Campaign from your Webex Connect Contact Policy module by approximately 5:15 am every day. Therefore, when you activate the above deployment, messages will be sent only to those MSISDNs which were present in the allow list (i.e. opted-in) as of ~5:15 am that morning. So any new MSISDNs opted-in (and added to the ‘Allow list’) after 5:15 am, will not be part of this deployment’s target group today.
e) On the other hand, any MSISDNs which have opted-out of the ‘Allow list’ after ~5:15 am in the morning, will still be part of this deployment’s initial target group. However, before every message is pushed to the mobile operators’ SMS networks, Webex Connect will check against the specified ‘Allow list’ that the MSISDN’s CONSENT value is still ‘true’ and the value of the ‘EXPIRES’ field is still in the future. Thus, Webex Connect will automatically suppress the messages to those MSISDNs which have opted out since ~5:15 am in the morning.
Usage notes:
a) More information is provided later in this release note about how this ‘external suppression’ within ‘Webex Connect Contact Policy’ is represented on the Dashboard and Reports.
b) You cannot use more than one ‘Contact Policy allow list’ as a Target group source within a deployment; nor can you mix this TG source with any other type of TG source.
c) Webex Campaign will retrieve only ‘allow lists’ from your Webex Connect Contact Policy; i.e. You cannot use a ‘deny list’ as a Target group source.
d) You can use ‘Contact policy allow lists’ only within simple SMS Promotion deployments, i.e. Follow-up and A/B promotion deployments are out of scope for this feature. Similarly, instant deployments are out of scope for this feature.
e) If, due to some unforeseen reason, there is some problem in the early morning retrieval of the ‘Contact Policy Allow List’ into Webex Campaign, then:
a. the status will be changed to ‘Paused’ for any one-time (non-recurring) deployments which are using an ‘allow list’ as a Target group source, and
b. the status will be changed to ‘Pending’ for any recurring deployments which are using an ‘allow list’ as a Target group source. This scenario is conceptually similar to a ‘file missing from SFTP’ scenario when the TG source for a recurring deployment is SFTP. In this scenario, the deployment-creator will receive an email notification alert.
1.2 SMS promotion deployments: use a ‘contact policy allow list’ as an ‘inclusion list’
This is a tenant-specific feature; it is useful for those clients:
a) who use both Webex Campaign and Webex Connect for their various marketing and non-marketing use cases and
b) who use the optional module within Webex Connect called ‘Contact Policy’ to store and manage their customers’ opt-in and opt-out preferences for receiving communications via specific channels.
In this release, we have introduced integration of Webex Campaign with this ‘Contact Policy’ module for the following specific use case: We have introduced an ‘Inclusion List’ feature within the ‘Additional options’ node for SMS Promotions deployments. While configuring such a deployment, you can now select a ‘Contact Policy Allow List’ as the ‘Inclusion List’ when the Target Group source is ‘File’ or ‘SFTP’ or ‘Existing TG’. This feature is associated with the client-requested enhancement Nolt #400.
This feature is currently only available:
a) for SMS channel ‘simple promotion’ type deployments and
b) for clients who use Webex Connect as their SMS channel gateway.
The use case supported by this feature is as follows: You have a Target Group file to be used for sending out SMS communications; and you want to scrub this file against a specific ‘Contact Policy Allow List’ stored within your Webex Connect tenant to ensure that you comply with the SMS channel opt-in preferences of your customers.
Pre-requisites for using this feature are the same as mentioned in the previous subsection.
How to use this feature (i.e. use a ‘Contact Policy Allow List’ as an ‘Inclusion list’ while configuring a deployment):
a) When creating an SMS Promotion deployment, you can drag and drop any of the following 3 nodes on the ‘Target group’ placeholder node in the central canvas: ‘Existing TG’ or ‘File’ or ‘SFTP’. Then click on the ‘Save changes’ button on the right-side properties panel for that Target group node.
b) Next, click on the 3-dots menu on the ‘Additional options’ node. Among the 6 actions available, click on the newly introduced action of ‘Add inclusion list’.
c) Then, a new placeholder node called ‘Add inclusion’ will appear to the right of the ‘Additional options’ node.
d) Next, drag and drop the newly introduced ‘Contact policy group’ node from the left panel onto the ‘Add inclusion’ placeholder node. This is the only node from the ‘Target group source’ nodes that you can use as an ‘Inclusion list’.
e) Next, you will need to click on the ‘Add’ link on the right-side node properties panel to select one of the allow lists. These allow lists would have been retrieved in the morning into Webex Campaign from your Webex Connect Contact Policy module.
f) Next, you will need to save the ‘Contact policy group’ node. Next, you will need to configure the schedule and SMS content nodes as usual; then save the deployment and activate it as usual.
g) When you activate this deployment, Webex Campaign will push the personalized SMS message to the MSISDN found in each record within the Target group via Webex Connect and it will also pass to Webex Connect, the ID of the ‘Allow list’ that you have specified as the ‘Inclusion list’.
h) In turn, before every message is pushed to the mobile operators’ SMS networks, Webex Connect will check against the specified ‘Allow list’ that the MSISDN’s CONSENT value is still ‘true’ and the value of the ‘EXPIRES’ field is still in the future. Thus, Webex Connect will automatically suppress the messages to those MSISDNs which have opted out , even if such MSISDNs are present in your Target group file.
1.3 Change TPS quickly from the ‘Campaign details’ screen (without pausing the deployment)
You can now quickly change the TPS (throughput transactions per second) for a deployment in the ‘Running’ or ‘Pending’ status without having to pause the deployment. This ‘Change TPS’ action is now available from the ‘3-dot action menu’ on the following screen: ‘Campaign details – Deployments in this campaign’.
This feature is associated with the client-requested enhancements Nolt #451 and Nolt #458.
On the following pop-up, you can specify the new TPS value, which will be effective in the next 2-3 minutes after you click on the ‘Change TPS’ button.
Usage notes:
a. This feature is not applicable to ‘Instant deployments’.
b. This feature is not applicable to ‘A/B promotion’ deployments.
c. This feature is not applicable to SMS deployments for which the ‘Auto TPS’ option has been selected.
d. This feature is not applicable to SMS deployments which have the ‘Auto TPS’ option enabled.
e. If a deployment is saved in a ‘draft’ status, and the router has not yet been assigned to the deployment, then it is not possible to change the TPS; you will first need to assign a TPS to be able to change it.
f. The ‘Update SMS Deployment API’ has also been amended to allow you to change TPS via API.
1.4 Additional columns added to the deployments list grid on the ‘Campaign details’ screen
Based on client feedback, we have made the following improvements on the following screen: ‘Campaign details – Deployments in this campaign’:
a. Introduced a new column for ‘Pending #’. This column will show the number of records in that deployment’s target group which are yet to be processed.
b. Introduced a new column ‘TPS’. If the deployment is in ‘Draft’ status and the user has not yet configured the TPS for the deployment, then this column value will be blank.
c. Added the timestamp in ‘HH:MM’ format to the ‘Next send date’ column. This timestamp will be shown according to the logged-in user’s timezone. The timestamp of the ‘next send date’ will be shown for deployments in the following statuses: ‘Draft’, ‘Pending’, ‘Running’, and ‘Approval pending’. Timestamp is not shown for deployments whose schedules are configured such that messages are to be delivered in the ‘local timezone of recipients’.
d. Renamed the column heading ‘# Contacts in target group’ to ‘TG contacts #’.
e. Added the ability to sort all the columns in this grid.
This feature is associated with the client-requested enhancements Nolt #440, Nolt #450 and Nolt #452.
1.5 Added ‘seed list’ info on the ‘Deployment info’ hover pop-up panel
This feature is associated with the client-requested enhancement Nolt #407.
1.6 SMS / MMS deployments: A custom header instead of the ‘MSISDN’ within a Target Group file
This is a tenant-specific feature. For new clients, Webex Campaign will now support the use of a custom header instead of the ‘MSISDN’ header within your target groups (e.g. ‘CTN’, ‘Cellphone’ etc.).
This feature is associated with the client-requested enhancement Nolt #363.
Usage notes:
a) This is a tenant-specific feature. If you would like to enable this feature for your tenant, please contact your Cisco Webex representative or the Webex CPaaS Tech Support team. You will need to provide the name of the custom header that you would like to use within your target group files, instead of the default ‘MSISDN’ header (e.g. ‘CTN’, ‘Cellphone’ , ‘Mobile_number’, etc.)
b) This feature is only applicable to SMS and MMS channels.
c) At the time of Target group (TG) creation, Webex Campaign will check within the TG file, whether the specified custom header is present within your TG. If the specified custom header is found, then Webex Campaign will ingest the file and internally convert that header to the default ‘MSISDN’ header while creating the TG. All the internal file processing will take place using this ‘system-native’ MSISDN header. Therefore, if you download the same target group again from Webex Campaign, it will have the ‘MSISDN’ header and not your custom header.
d) Specifically, this feature is applicable to the following TG creation scenarios:
i. Static TGs created from TG-source = ‘File’
ii. Static TGs created from TG-source = ‘SFTP’
iii. Dynamic TGs created from TG-source = ‘SFTP’
iv. Dynamic TGs created from TG-source = ‘SFTP’ and where the user uploads a ‘sample file’
e) Specifically, this feature is manifested on the following UI screens:
i. ‘Create target group’ pop-up on the ‘Target groups’ list screen
ii. Deployment canvas (when you drag-and-drop the ‘File’ or ‘SFTP’ nodes from the left panel to the central canvas
iii. Seed lists, exclusion lists, inclusion lists which are added on the deployment canvas
iv. Files used for ‘file-drop’ initiated event-triggered instant deployments
f) This feature is not applicable to dynamic TGs created from TG-source = ‘Segment Builder’. In this scenario, you can use the existing ‘ALIAS’ feature within the Segment Builder to change the header from your custom header, say CTN, to the standard default header ‘MSISDN’.
g) For personalization and conditional logic within the SMS / MMS message content, you will need to use the $(TG_MSISDN) attribute.
h) On all the applicable screens within Webex Campaign, the default header label ‘MSISDN’ will be displayed (e.g. Preview & Test, Customer Care, Dashboard, Reports etc.)
i) All the pre-configured reports will continue to display the default header label ‘MSISDN’.
j) If your TG file contains both the headers, MSISDN and your specified custom header, then that file will be rejected by Webex Campaign as an invalid file and the TG will not be created.
k) Similarly, if the file used for ‘file-drop’ initiated event-triggered instant deployments, has records which contain both the headers, MSISDN and your specified custom header, then such records will be rejected by Webex Campaign.
l) This feature is not applicable to API-initiated event-triggered instant deployments; i.e. if you want to use the mobile number of a message recipient as one of the event parameters, then you will need to define that parameter as ‘MSISDN’ and not as your specified custom header name.
1.7 SMS / MMS: Timezone-aware deployments – Reduced the lead time to 15 mins (from 1 hour)
This is a tenant-specific feature which was originally introduced in release 6.6 and is available only to tenants hosted in AWS-USA and AWS-Canada.
Previously, if a deployment has the option enabled for “Send using local time zone of recipient”, then you could not schedule the deployment within the next one hour if you were based in the Eastern time zone in the USA or Canada. Similarly, if you were based in the Central time zone in the USA or Canada, then such ‘timezone-aware’ deployments had to be activated at least 2 hours in advance of the intended send time of the deployment. Similar restrictions of 3 hours and 4 hours were in place for Mountain and Pacific time zones respectively.
In this release, we have made some backend infrastructure changes loosen these restrictions as explained below.
New reduced lead times for USA-hosted clients if you are in the below time zones are as follows:
a) US Eastern: Schedule lead time reduced from 1 hour to 0 hour (i.e. no restriction on lead time; you can schedule the deployment to go out immediately after activation).
b) US Central: Schedule lead time reduced from 2 hours to 1 hour
c) US Mountain: Schedule lead time reduced from 3 hours to 2 hours
d) US Pacific: Schedule lead time reduced from 4 hours to 3 hours
e) US Alaska: Schedule lead time reduced from 5 hours to 4 hours
f) US Hawaii: Schedule lead time reduced from 7 hours to 6 hours
New reduced lead times for Canada-hosted clients if you are in the below time zones are as follows:
a) Canada Atlantic & Eastern: Schedule lead time reduced from 1 hour to 0 hour (i.e. no restriction on lead time; you can schedule the deployment to go out immediately after activation).
b) Canada Central & SK : Schedule lead time reduced from 2 hours to 1 hour
c) Canada Mountain: Schedule lead time reduced from 3 hours to 2 hours
d) Canada Pacific: Schedule lead time reduced from 4 hours to 3 hours
1.8 Recurring deployments: continually processing multiple target files in a single schedule
For recurring deployments, we have introduced a new checkbox option within the ‘Target group’ nodes (i.e. ‘SFTP’ and ‘Existing TG’ nodes) called ‘Look for new files in SFTP every 10 minutes to append to this TG’.
This is a tenant-specific feature and will be made available to clients who have a specific use case which requires this feature.
In effect, this feature can reduce the need for manual intervention (by using the existing ‘Deploy now’ feature) when multiple or delayed files are expected to be processed within the schedule of a recurring deployment.
Usage notes:
a) As this is a tenant-specific feature, if you are interested in this feature, you will need to request the Webex CPaaS Tech Support team to enable this feature on the Webex Campaign Admin Console.
b) This feature is currently available only for SMS & MMS channel recurring simple promotion type deployments whose Target group type is ‘dynamic’.
c) This feature is available for deployments which have the option enabled for “Send using local time zone of recipients”.
d) This feature is not available for A/B promotion deployments.
e) This feature is not available for instant deployments.
f) This feature is useful in case of recurring deployments which have the TG-source of SFTP and if you are expecting to receive an unknown or unpredictable number of files in the SFTP from your upstream 3rd party systems during the daily / weekly / monthly schedule slot. Previously, such recurring deployments would have processed only one file during the schedule slot. However, now with the introduction of this feature, the system will continue to check for the arrival of new files every 10 minutes until the end of the schedule slot on that day. Every subsequent file will in effect be appended to the already existing Target group.
g) The TG count will be updated after the newly arrived file is appended to the TG.
h) If you forgot to enable this option initially when activating a recurring deployment, then you may pause the deployment, then enable this option and resume the deployment again.
1.9 SMS / MMS Sender-IDs: Support for special characters
In order to support clients in Canada and South America where French, Spanish and Portuguese languages need to be supported, we have loosened the restrictions on the characters that are allowed when SMS / MMS Sender-IDs are created. (Campaign management >> Assets >> Sender IDs). This feature is associated with the client-requested enhancement Nolt #438 and ServiceNow ticket PRB0010022.
With this release, you can create Sender-IDs containing ‘space’ and ‘underscore ( _ )’ characters. In addition, for non-English languages, you can create Sender-IDs containing the following special characters: ‘acute accent’, ‘grave accent’, ‘circumflex accent’, ‘tilde’ and ‘cedilla’. These special characters will be supported in both upper case and lower case.
Please note that although such Sender-IDs will now be allowed to be created within Webex Campaign, ultimately these Sender-IDs also need to be allowed by the specific SMS / MMS message gateway being used within your tenant and in turn, the mobile operators within your country. This validation cannot be done by Webex Campaign when you are creating the Sender-ID on the above screen. Please ensure you contact the Webex CPaaS Support team to confirm that these Sender-IDs are indeed supported by the mobile operators within your country.
1.10 Accessibility improvements
We have continued to make various improvements to Webex Campaign to improve the UI’s accessibility according to the WCAG criteria (‘Web Content Accessibility Guidelines’). Specifically, in this release, we have focused on improving compliance with the below WCAG accessibility guidelines:
• WCAG 2.1 Criterion 1.3.1(A) Info and relationships ( i.e. Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.)
• WCAG 2.1 Criterion 3.3.2(A) Labels or instructions (i.e. Labels or instructions are provided when content requires user input.)
2.0 Dashboard and Reports module enhancements
2.1 Ability to ‘Switch User Group’ from Dashboard and Reports screens
Now you will be able to ‘Switch User Group’ from Dashboard and Reports screens.
2.2 Contact policy suppressions in Dashboard & Reports
As previously mentioned in sections 2.1 and 2.2 of this release note, Webex Connect will suppress messages sent to any MSISDNs which have not opted in to receive the SMS communications as per the specified ‘Contact Policy Allow List’.
These MSISDNs are counted and shown on the Dashboard under the category of “External suppressions (e.g. CP)”.
In the ‘Promotion Transaction Report’, the ‘STATUS’ of these MSISDNs will be shown as “Not Pushed” and the ‘STATUS DESCRIPTION’ will be shown as “Suppressed-CP”.
2.3 Accessibility improvements
We have continued to make various improvements to Webex Campaign to improve the UI’s accessibility according to the WCAG criteria (‘Web Content Accessibility Guidelines’).
Specifically, in this release, we have focused on improving compliance with the below WCAG accessibility guidelines:
• WCAG 2.1 Criterion 1.3.1(A) Info and relationships
• WCAG 2.1 Criterion 3.3.2(A) Labels or instructions
3.0 Email Composer module enhancements
3.1 Support for personalized images by getting the image URL as a TG-Header or EV-Param (BETA)
This feature currently only works on emails opened on desktop email clients. In the next release, we will implement the improvement to support email clients on mobile devices.
This feature will enable you to specify a URL of an image within the email composer to be retrieved from a target group (for promotion deployments) or from an event-parameter (for instant deployments). This will enable you can design an email such that a different personalized image is shown to every email recipient.
This feature is associated with the client-requested enhancement Nolt #424.
Now you will see a new source for images called “TG header/Event parameter” available in the ‘Select Image from’ dropdown on the right-side panel for the ‘Image’ block.
If you select this option from the dropdown, then a pop-up will appear showing the associated list of Target group headers (or list of Event-params). Here you will need to select the TG Header which contains the personalized image URL for each email recipient. (In the below example screenshot, this TG Header is “TG_IMGRANDOM”).
After you click on the ‘Save’ button on this pop-up to select the TG Header corresponding to the image URL, a placeholder image will be displayed as shown in the below screenshot. When this email template is used in an email deployment, and after the deployment is activated, a different personalized image will be rendered for each email recipient corresponding to the image URLs in the TG file.
Usage notes:
a) As the images are personalized and the image URLs will become available only during the deployment ‘run time’ from the TG, we recommend that you conduct a thorough testing of such deployments, paying close attention to the aspect ratio and height settings of the images hosted at the personalized URLs in the Target Group or the Event params.
b) Same image settings will be applicable for mobile and desktop devices
4.0 Profile Manager module enhancements
4.1 UX improvements in the Segment Builder screens
We have made many UX improvements in the Segment Builder screens as can be seen in the below screenshots.
4.2 Added a validation check when adding a ‘Datastore’
We have enhanced the UX to provide a clear message and a smoother workflow when adding a new datastore using ‘SFTP/ AWS S3’ as the data source type. Previously, if no "Data Exchange" was configured, the "Create Datastore" flow would end abruptly, and the subsequent screen would not render properly, under certain conditions.
Now, when you select ‘SFTP/ AWS S3’ as the data source type and click proceed, a background check runs to verify if any prerequisite configurations are missing. If prerequisites are missing, a notification message is displayed indicating the issue. If all prerequisites are met, you can proceed to create the datastore. This enhancement handles the workflow and edge cases more elegantly, ensuring a seamless user experience.
5.0 Maintenance items in this release
| # | Module | Change Type | Description |
|---|---|---|---|
| 1 | Engineering | Improved | We have improved one aspect of the backend infrastructure in this release by upgrading MongoDB Atlas from v5.0.26 to v6.0.15. [CMPN-20436] |
| 2 | Engineering | Improved | We have improved one aspect of the backend infrastructure in this release by upgrading the Dashboard/ Reports UI Angular framework from v5.x to v8.x. [CMPN-20620] |
| 3 | Engineering | Improved | We have improved one aspect of the backend infrastructure in this release by upgrading the version of AWS-EKS (Elastic Kubernetes Service) from v1.28 to v1.29 for the Campaign Manager module. [CMPN-20181] |
| 4 | Engineering | Improved | We have improved one aspect of the backend infrastructure in this release by migrating ‘event queues’ from ‘FileQ’ to ‘Kafka’ for the DEV environment. [CMPN-20491] |
| 5 | Engineering | Improved | We have improved one aspect of the backend infrastructure in this release by upgrading the version of AWS-MSK (Managed Streaming for Kafka) from v2.8.1 to v3.5.1 [PRB0011247 / CMPN-20335] |
| 6 | Dashboard / Reports | Improved | Dashboard >> SMS and MMS Deployment Details : On the ‘Engagement’ card’s tabular view, we have added a line to display ‘Unique clicks’ count. [CMPN-18115] |
| 7 | Dashboard / Reports | Improved | Dashboard>> Email Deployment Details: On the ‘Engagement’ card’s tabular view, we have renamed the ‘Unsubscribe rate’ to ‘Total clicks on unsub links’ as this is a better description of the metric being shown. [CMPN-18105] |
| 8 | Campaign Manager | Improved | We have improved MMS SenderID format configuration options based on feedback from a Brazil-based mobile telecom client whose MMSC require different MM7 packet format depending on whether the MMS SenderID is alphanumeric or numeric. [INC0479652 / CMPN-20486] |
| 9 | Campaign Manager | Improved | We have improved the behavior of the Left Navigation Bar’s ‘hamburger control’ at the top left corner to improve accessibility. [CMPN-20398] |
| 10 | Campaign Manager | Improved | We have improved the accessibility by improving several text labels on the UI across several screens such that button labels and placeholder texts within text boxes are more descriptive. This will help when a user is using screen-readers to navigate the UI. [CMPN-20346]. |
| 11 | Campaign Manager | Improved | Enhanced our ability to accurately identify the iOS devices and be able to deliver iOS specific content to the iOS devices with greater precision. [ PRB0010767 / INC0058618 / CMPN-19858] |
| 12 | Campaign Manager | Fixed | For the API channel integration between Webex Campaign and Webex Connect, we have improved the retry mechanism to implement it based on Webex Connect’s webhook response codes.[ INC0467934 / CMPN-20331] |
| 13 | Campaign Manager | Fixed | Improved our systems (including REDIS) to ensure the TPS (Transactions Per Second) counter resets properly when server instances scale down. This prevents interruptions to normal operations and avoids delays in email delivery. [PRB0011370 / INC0503236 / CMPN-20555] |
| 14 | Campaign Manager | Fixed | Updated our system's error-handling logic to prevent any errors from disrupting other scheduled tasks. This improvement ensures that email campaigns run properly, even if an error occurs. [PRB0011099 / INC0412525 /CMPN-20557] |
| 15 | Campaign Manager | Fixed | We improved the way we store target group count values in our system's backend, ensuring they are updated consistently across different UI screens. Specifically, this issue was affecting the ‘contact count’ value shown on the ‘Deployment list’ and ‘Deployment summary’ screens. [PRB0010959 / PRB0010717 / INC0347937 /CMPN-19407] |
| 16 | Profile Manager | Fixed | Further improved our ETL process to detect and handle outdated files. This would eliminate the possibility of any downstream issues and user errors. [PRB0011064 / INC0327711 / CMPN-20558] |
| 17 | Profile Manager | Fixed | Enhanced our backend data storage structures for Datastores, which previously prevented users from editing Datastore fields in some rare cases. [PRB0010371 / INC0120718 / CMPN-18784] |
| 18 | Profile Manager | Fixed | We further enhanced and fine-tuned our backend systems to ensure robust and error-free data synchronization between Datastore and Profiles. [PRB0010697 / INC0257894 / CMPN-18990] |
| 19 | Profile Manager | Fixed | We have added validations on the Segment Builder step 3 (‘Output headers’) while creating Follow-up deployments to prevent the user from changing / deleting any headers because in case of follow-up deployments, the output headers should be inherited from the parent deployment. [PRB0010132 / INC13753724 / CMPN-18725] |
| 20 | Dashboard / Reports | Fixed | Enhanced the ‘MMS Preview’ feature by using the logged-in domain to generate the preview URL instead of the primary domain. This prevents any failures when displaying the preview with valid domains, while still adhering to all security policies. [PRB0049391 / INC13467047 / CMPN-20564] |
| 21 | Campaign Manager | Fixed | Resolved an issue that prevented the restarting of a campaign deployment when users quickly paused and resumed activity. [PRB0010561 / INC0223154 / CMPN-18961] |
| 22 | Campaign Manager | Fixed | Fixed an issue where the system didn't automatically record unexpected problems, needing the support team to step in manually. This issue made it seem like email delivery rates were dropping for users in the meantime. [PRB0010009 / CMPN-20947] |
| 23 | Campaign Manager | Fixed | Fixed an issue that, under certain conditions, prevented French characters in MMS/SMS content from being displayed properly. [PRB0011413 / INC0483231 / CMPN-20490] |
| 24 | Campaign Manager | Fixed | Resolved an issue that occurred when trying to pause a running deployment under certain conditions. The error was caused by a discrepancy in how we stored deployment data between UI updates(Old vs. New). [PRB0010505 / INC0191646 / CMPN-18819] |
| 25 | Campaign Manager | Fixed | Resolved an issue where the previously added feature allowing users to enter a TPS value in the schedule node for the email channel was not working for certain types of email deployments if the email content included conditional logic. This limitation caused deployments to be processed instantly, despite having a specified TPS value. [PRB0010508 / INC0179661 / CMPN-18818] |
| 26 | Campaign Manager | Fixed | Resolved an issue where allowing a space character in user-group names caused multiple problems across different screens. These problems included newly created email templates not appearing in the template list, newly created media assets not showing up in the media tab, and other related issues. [PRB0010291 / INC0100647 / CMPN-18530] |
| 27 | Campaign Manager | Fixed | Fixed an issue with the creation of the URL for the landing page, where placeholders were appended incorrectly. This caused links on the landing page to not route correctly when users clicked on them. [PRB0010140 / INC0019312 / CMPN-18397] |
| 28 | Campaign Manager | Fixed | Resolved an issue where not allowing special characters, such as underscore, when creating a SenderID for SMS and MMS channels was preventing users from creating a SenderID. [PRB0010022 / INC0013004 / CMPN-18391] |
| 29 | Profile Manager | Fixed | Resolved an issue that occurred under intermittent scenario while attempting to update the Profile. The incorrect value to ‘Attribute type’ in the backend was preventing the Profile from being updated. [PRB0011242 / INC0413839 / CMPN-20565] |
| 30 | Profile Manager | Fixed | Fixed a bug, which under a specific scenario was preventing the users from saving the ‘Profiles’. [PRB0010209 / INC13774018 / CMPN-18490] |
| 31 | Profile Manager | Fixed | Resolved an issue where extra spaces were being added to attribute names when creating profiles. This sometimes disrupted downstream processes like segment execution. [PRB0011355 / INC0455691 /CMPN-20556] |
| 32 | Dashboard / Reports | Fixed | Resolved an issue related to report generation and scheduling. Only when the report is picked for generation, its schedule should be updated, whereas earlier 5 reports were being picked for generation. But, the schedule was not being updated for all the reports. This was leading to a scenario where some automated reports were not being delivered.[PRB0010335 / CMPN-18766] |
6.0 Need more information?
Please contact your Cisco Webex client representative if you have questions or would like access to a new feature.
Cisco Webex technical support team can be contacted at any time by phone or email:
- Europe / Middle East / Africa:
- Phone: +44 (0) 1494 750 600
- Email: [email protected]
- North America:
- Phone: +1-855-324-0970
- Email: [email protected]