Summary

Enhanced the Journey Engine to support date-based conditions for actions, allowing actions to become available or expire within configured date windows.

Overview

Previously, Journey actions could be sequenced based on completion of previous steps, but they did not support calendar-based start and end dates. This limited the ability to configure campaigns where actions must be completed on specific dates or become available according to a predefined schedule. 

The enhancement introduces optional Start Date and End Date fields for actions, both inside and outside Event Groups. These fields can be configured independently or together to support different journey requirements.

The enhancement supports two key use cases: Advent Calendar Journeys, where each action is available only on its assigned date and missed actions cannot be completed later, and Previous Action-Based Journeys, where actions remain available for catch-up but the next action unlocks only after its scheduled date arrives and the previous action is completed.

The Journey Configuration API and User Journey API are also enhanced to expose the date fields and support the status information required to display actions as locked, available, completed, or blocked.

Key Highlights

Impact

Summary

Enhanced the V1 Create Segment API to support segment creation and the import of segment users into the MySQL database.

Overview

The V1 Create Segment API has been updated to support the required changes for segment creation in the legacy platform.

The enhancement also includes support for importing segment users into the MySQL database, ensuring that users associated with newly created segments can be properly imported and maintained in the legacy system.

The changes were completed at the code level and unit tested successfully, including validation of the segment user import flow.

Key Highlights

Impact

Summary

Fixed an issue where editing a live Tier V2 program could incorrectly change its program status, causing members to receive no current tier information.

Overview

The issue occurred when changes were made to an already live Tier V2 program. The program could remain live in one system while being incorrectly marked as draft in another, resulting in a mismatch in program status.

Because current-tier evaluation depends on the live program status, this mismatch could prevent the system from identifying the active program and returning the member's current tier. As a result, affected members could see no tier information instead of their expected current tier.

The program update logic has been corrected so that editing a live Tier V2 program preserves its live status and keeps program information synchronized correctly.

Key Highlights

Impact

Summary

Implemented PostgreSQL synchronization support for user extended attribute updates performed through the S33 Raas module.

Overview

The S33 user profile update flow was enhanced to synchronize changes made to user extended attribute values with the PostgreSQL database.

The update flow now integrates with the user Sync API to ensure attribute status and value changes made through the S33 module are correctly reflected in PostgreSQL.

The functionality was tested and confirmed to be working as expected.

Key Highlights

Impact

Summary

Added support for displaying the Spend to Maintain Tier information in the Tiers V2 iFrame for members who are within their tier retention period.

Overview

The Tiers V2 iFrame has been enhanced with additional standard fields to provide members with visibility into the requirements for maintaining their current tier during the retention period.

The enhancement adds support for displaying the member's retention status, current tier display name, and the required spend to retain the current tier. The required spend information is shown only when the member is within the tier retention period.

The functionality was tested and confirmed to be working as expected for users in applicable retention scenarios.

Key Highlights

Impact

Summary

Fixed an issue where a tier upgrade notification could be sent to Klaviyo even though the corresponding tier change was not actually recorded for the member.

Overview

The tier upgrade flow was generating a tier change event based on an invalid or incomplete tier record. In certain scenarios, a PAR tier record was added to the Tier Earned table without a corresponding entry in the tier tracking data.

This resulted in an incorrect tier change event being triggered, while the member's actual tier history remained unchanged.

The fix ensures that a PAR tier record is added to the Tier Earned table only when there is a valid tier change, preventing incorrect tier upgrade notifications from being generated.

Key Highlights

Impact

Summary

Fixed an issue with Dashboard Summary Report processing where notification emails could be sent before the report was successfully completed, resulting in reports appearing as ready while still showing an in-progress status.

Overview

Improvements were made to the Dashboard Summary Report generation workflow to ensure that completion notifications are sent only after the corresponding report request has successfully finished.

The issue was also investigated for reports that became stuck during processing. The investigation identified high server memory utilization as a cause of report processes being terminated, particularly for reports involving large data volumes.

The updated handling improves the accuracy of report completion notifications and reduces the possibility of users accessing reports that are still being generated.

Key Highlights

Impact

Summary

Summary

Enhanced the Refer-a-Friend (RAF) APIs by introducing additional response parameters and optional email control to improve referral tracking and integration flexibility.

Overview

Enhancements were implemented for the Referral Status and Send Email RAF API endpoints to provide additional referral information and greater control over email delivery.

The Referral Status API now includes the generated shortened referral link within the response, enabling applications to retrieve and display referral URLs directly. The Send Email API has also been enhanced to return the generated shortened referral link after successful processing.

Additionally, an optional skip_email_send parameter was introduced to the Send Email API, allowing integrations to generate a successful response without sending an email when required, while preserving the existing behavior when the parameter is omitted.

Key Highlights

Impact

Summary

Summary

Corrected the Tier v2 eligibility calculation to exclude cancelled order spend from tier evaluation, ensuring accurate tier assignments and reporting.

Overview

The Tier v2 eligibility calculation was enhanced to ensure cancelled order amounts are no longer included when determining a member's qualifying spend for tier progression.

Previously, spend associated with cancelled products could be counted toward tier qualification, resulting in members being assigned higher tiers than they were eligible for. The enhancement updates the tier calculation logic to consider only valid purchase amounts, ensuring accurate tier eligibility, API responses, and reporting.

The updated logic was validated across multiple order scenarios, including different products, multiple quantities, multiple orders, and partial or full order cancellations.

Key Highlights

Impact

Summary

Enhanced synchronization between legacy and PostgreSQL systems across multiple ADR modules, improving data consistency for campaigns, rewards, badges, stores, translations, and administrative configurations.

Overview

A series of synchronization improvements were implemented to address inconsistencies across multiple ADR components. The enhancements ensure that updates performed through the administration interface are consistently synchronized between supported data stores, improving data accuracy and operational reliability.

The implementation includes synchronization enhancements for campaign groups, badge status updates, reward images, bulk reward operations, stores, translations, and campaign milestone processing. Additional improvements were made to maintain consistent campaign milestone values during synchronization and to ensure delete and status update operations are properly propagated.

These updates improve the overall reliability of administrative data synchronization while reducing inconsistencies across supported modules.

Key Highlights

Impact

Summary

Optimized SQL queries for the ADR Points Report and Liability Report to improve search performance when filtering by specific member identifiers.

Overview

Performance improvements were implemented for the ADR reporting module by optimizing both the listing and count SQL queries used in the Points Report and Liability Report.

The optimization specifically targets commonly used search filters to reduce query execution time and improve report responsiveness.

The following enhancements were completed:

• Points Report: Optimized SQL queries for Name and Email filters.
• Liability Report: Optimized SQL queries for UID and Email filters.

The optimized queries were validated in the Develop and Stage Beta environments before being scheduled for production deployment.

Key Highlights

• Optimized listing SQL queries for the ADR Points Report.
• Optimized count SQL queries for the ADR Points Report.
• Improved Name and Email filter performance in the Points Report.
• Optimized listing SQL queries for the ADR Liability Report.
• Optimized count SQL queries for the ADR Liability Report.
• Improved UID and Email filter performance in the Liability Report.

Impact

• Improves report loading performance for filtered searches.
• Reduces SQL execution time for commonly used search criteria.
• Enhances responsiveness of ADR reporting.
• Provides a more efficient reporting experience for administrators.

Summary

Improved the group tier assignment process to prevent intermittent tier drops by optimizing tier update logic and eliminating unnecessary tier reassignment operations.

Overview

Enhancements were made to improve the reliability and consistency of group tier assignment during group creation and subsequent tier evaluation.

The implementation addressed an issue where unnecessary delete-and-add operations were performed during group tier assignment, which could temporarily remove an existing group tier before reassigning the same tier. Since the synchronization process executes asynchronously, this intermediate state could result in incorrect group tier values being displayed.

The solution introduces validation to prevent redundant tier removal when the assigned tier remains unchanged, ensuring stable group tier synchronization while preserving existing upgrade and downgrade workflows.

The changes were validated across multiple tier assignment scenarios, including credit, debit, order-based upgrades, downgrades, and scenarios where no tier change occurs.

Key Highlights

Impact

Summary

Enhanced the Member Update webhook event payload by improving field consistency, removing unnecessary metadata, and providing complete member information for update and opt-in/opt-out events.

Overview

Enhancements were made to the Member Update webhook event to improve payload consistency and usability for downstream integrations.

The implementation removes unnecessary metadata fields from the webhook payload while ensuring member details such as email, first name, and last name are always populated with actual values instead of null during update events.

Additionally, the webhook now includes structured change tracking for opt-in and opt-out actions by populating the changes object with the previous and updated opt-in status. These improvements provide a more consistent event structure, simplify webhook consumption, and improve the accuracy of member update notifications.

Key Highlights

Impact

Summary

Enhanced the Reward Awarded and Badge Awarded webhook events by adding source information parameters while maintaining backward compatibility with existing webhook consumers. 

Overview

Enhancements were introduced to extend the Reward Awarded and Badge Awarded webhook payloads with additional source-related information.

The implementation adds two new parameters source_type and source_id to both webhook events. These parameters mirror the existing awarded_by and journey_id values, providing clearer source information for rewards and badges that are manually assigned through different systems.

The existing awarded_by and journey_id fields continue to be supported to ensure backward compatibility with current integrations. This approach allows external systems to adopt the new parameters without impacting existing webhook implementations.

The enhancement improves consistency across manual reward and badge assignment workflows while preparing the webhook contract for a future transition to standardized source parameters.

Key Highlights

Impact

Summary

Enhanced the handling of Points to Expire and Next Points Expiration Date across the Weekly Reconciliation Report, Get Points API, and ADR to ensure consistent behavior for customers with rounded point balances and zero expiring points. 

Overview

Improvements were made to align the calculation and display of Points to Expire and Next Points Expiration Date across multiple interfaces, including the Weekly Reconciliation Report, ADR, and the Get Points API.

The enhancement addresses scenarios where fractional point balances are rounded to zero based on the client's configured point formatting. Previously, customers with zero displayed expiring points could still receive an expiration date, creating inconsistencies between reports and APIs. 

The updated implementation ensures that expiration dates are handled consistently when no points are scheduled to expire, while preserving the client's configured point-rounding behavior. 

Key Highlights

Impact

Summary 

Completed production deployment activities for the Bluecore ESP application across supported environments following successful development, testing, and release validation. 

Overview 

The changes ensure that the latest Bluecore ESP functionality is available across supported production environments while maintaining deployment consistency through the established release workflow. 

Impact  

Summary 

Implemented a new visibility condition for the Pro Partner Resources page based on the ZPreferredLanguage_KUT attribute. 

Overview 

A new access control condition has been introduced to restrict visibility of the Pro Partner Resources page. The page will now be displayed only to users whose profile matches the configured value of the ZPreferredLanguage_KUT attribute. 

This enhancement ensures that the page content is shown only to users with the appropriate language preference, improving content relevance and user experience. 

The change is limited to UI-level visibility logic and does not impact existing functionality or data processing. 

Key Highlights 

Impact 

Performance Improvement – Get Points API Optimization 

Ticket: LB-5328 

Summary 

Optimized the Get Points API to reduce response time delays experienced by some users prior to redemption actions. 

Overview 

An issue was identified where the Get Points API response time was significantly high for certain users, particularly before initiating a points redemption call. This impacted the overall user experience and slowed down dependent workflows. 

Analysis revealed that specific calculations and data retrieval (including fields like totalSpent and other aggregated values) were contributing to increased response time. Additionally, inefficiencies in SQL queries and ADR-side processing were identified. 

To address this, optimization changes were implemented across both API logic and database queries, along with improvements on the ADR side to streamline data handling. 

 Key Highlights 

Impact 

Summary 

Resolved an issue related to incorrect or missing update date values for both regular and external rewards, ensuring accurate synchronization across systems. 

Overview 

An issue was identified where the update date field for rewards was not being consistently updated during reward modifications, impacting both regular and external reward types. 

This caused discrepancies in tracking reward updates and affected downstream processes relying on accurate timestamps. 

The fix involved updating the reward update logic to ensure that: 

Additional validation was performed to ensure compatibility with reward eligibility logic and existing reward configurations. 

Key Highlights 

 Impact 

Summary 

Resolved an issue where the date parameter in store attributes was not syncing correctly, ensuring accurate data storage and consistency across systems. 

Overview 

An issue was identified in the store attribute synchronization process where date-type parameters were not being properly handled during data sync. 

This resulted in incorrect or inconsistent date values being stored or transferred between systems, impacting features dependent on store attribute data. 

The fix involved correcting the data handling and formatting logic for date parameters to ensure: 

Key Highlights 

Impact 

Summary 

Implemented webhook trigger logic to notify external systems whenever a member’s points balance is updated through cron-based processes. 

Overview 

Enhancements were made to the loyalty scheduled job process to trigger webhook events whenever there is an update in a member’s points balance. 

Previously, points updates processed through scheduled jobs (such as rolling expiration and adjustments) were not triggering webhook notifications, leading to gaps in real-time data synchronization with external systems. 

To address this, webhook logic was integrated into the scheduled job flow, ensuring that any balance updates processed in the background are now captured and communicated via webhook events. 

The implementation ensures consistent behavior between real-time API updates and scheduled schuduled-based updates. 

Key Highlights 

Impact 

Summary 

Resolved issues in the Tier API where the next tier and tier expiration date were not correctly returned in the Python API response. 

Overview 

An issue was identified in the Tier API (Python) where users in higher tiers (specifically Tier 3 and above) were not receiving the next tier details in the API response. Additionally, the tier expiration date parameter was missing from the response. 

This behavior was inconsistent with the PHP API response, which correctly displayed both values. The issue occurred regardless of whether the Sequential Tier flag was enabled or disabled. 

The fix ensures that: 

The resolution aligns the Python API behavior with the expected system logic and existing PHP implementation. 

Key Highlights 

Impact 

Summary 

Implemented integration of the refreshed external homepage design, enabling an updated user interface and improved user experience. 

Overview 

A new homepage design was integrated as part of the external homepage refresh initiative. The update focuses on enhancing the visual layout, usability, and overall user experience. 

The integration involved embedding the updated design components into the existing platform structure while ensuring compatibility with current configurations and navigation flows. 

The refreshed homepage was validated through internal testing to ensure correct rendering, responsiveness, and functionality across key user journeys. The update is now prepared for rollout to client-facing environments. 

Key Highlights 

Impact 

Summary 

Implemented integration of the refreshed external homepage design, enabling an updated user interface and improved user experience. 

Overview 

A new homepage design was integrated as part of the external homepage refresh initiative. The update focuses on enhancing the visual layout, usability, and overall user experience. 

The integration involved embedding the updated design components into the existing platform structure while ensuring compatibility with current configurations and navigation flows. 

The refreshed homepage was validated through internal testing to ensure correct rendering, responsiveness, and functionality across key user journeys. The update is now prepared for rollout to client-facing environments. 

Key Highlights 

Impact 

Summary 

Implemented Action Series configuration sync by introducing a new Python Sync API and integrating it with ADR to ensure seamless data synchronization to Postgres. 

Overview 

As part of the Postgres migration initiative, a new sync mechanism was introduced for Action Series configuration. 

This included creating a dedicated Python Sync API to handle Action Series data and integrating the same within ADR to enable automatic synchronization. 

Enhancements were made to support full lifecycle operations including create, update, and delete for Action Series and associated milestone data. Additional validations and payload handling were implemented to ensure data consistency across systems.  

Special handling was also introduced for expiration-related fields to ensure proper mapping between MySQL and Postgres formats. 

Key Highlights 

Implementation 

Impact 

Summary 

Resolved an issue where campaign benefit points were not included in the points removed parameter after a partial return transaction. 

Overview 

An issue was identified in the points calculation logic during partial return scenarios, where the system failed to include campaign benefit-related points in the points_removed parameter. 

While base transactional points were being deducted correctly, the campaign benefit points associated with the order were not reflected in the response. This resulted in discrepancies between expected and actual points removed values. 

The issue was addressed by updating the calculation logic to ensure that both transactional and campaign benefit points are correctly considered during partial returns. 

Key Highlights 

Impact 

Summary 

Enhanced the Adjustment API to support updating existing order items and adding new items, enabling flexible handling of exchange and modification scenarios. 

Overview 

A limitation was identified in the Adjustment API where it did not support adding or modifying items in an order during certain flows, particularly: 

Previously, the API supported only limited operations such as shipping and returning items, which restricted clients from performing complete order lifecycle adjustments. 

Enhancements were implemented to extend the API capabilities, allowing: 

These changes ensure that the Adjustment API can now handle more complex order modification workflows aligned with real-world use cases.  

Key Highlights 

Impact 

Summary 

Integrated the Pro Partner Resources page into the Club Moen site navigation and implemented access restrictions based on user attributes. 

Overview 

A new Pro Partner Resources page was added to the Club Moen site to provide partners with access to specialized resources via an embedded portal. 

The page integrates external resource content using an iframe and is accessible through the site navigation. The navigation link has been positioned between Product Catalogue and My Account. 

Access to the page is restricted to specific user groups based on predefined attributes to ensure that only eligible users can view the content.  

Key Highlights 

Impact 

Summary 

Implemented webhook triggering logic when member points balances are updated through the loyalty rolling expiration scheduled job process. 

Overview 

Enhancements were made to the loyalty expiration scheduled job process to ensure webhook events are triggered whenever a member’s points balance is updated. 

Previously, balance updates occurring through the rolling expiration scheduled job did not consistently trigger webhook notifications. This created gaps for external systems relying on webhook events to track real-time changes in member point balances. 

The webhook logic has now been implemented within the rolling expiration scheduled job process to ensure that balance updates caused by scheduled expiration or adjustments trigger the appropriate webhook events. 

The changes were applied to the loyalty scheduled job responsible for handling rolling expiration calculations and point updates. 

Key Highlights 

Impact 

Summary 

Updated the Reward Report to ensure Order ID and Total Spend values are populated correctly for reward-related transactions. 

Overview 

An issue was identified in the Reward Report where Order ID and Total Spend values were not appearing for certain reward transactions. 

Upon analysis, it was observed that orders containing products with a unit price of zero resulted in a total spend value of 0, which caused the Total Spend field to appear blank in the report. 

To improve report clarity and ensure consistent reporting behavior, updates were implemented to properly populate Order ID and Total Spend values in the Reward Report where applicable. 

Additionally, cases involving coupon code reuse were reviewed and confirmed to follow standard system behavior, where reused coupon codes without an associated redemption are treated as new coupon entries. 

Key Highlights 

Impact 

Summary 

Resolved an issue where users were unable to apply multiple rewards through the AnnexCloud widget during Shopify checkout. 

Overview 

An issue was reported where customers attempting to apply multiple rewards (up to five) through the AnnexCloud widget on Shopify checkout encountered an error message, preventing successful reward application. 

Investigation revealed that the issue was related to reward status updates and API handling during the reward redemption process. In certain scenarios, the reward status was not being updated correctly when multiple rewards were applied in succession. This resulted in conflicts during the order API call, which prevented additional rewards from being applied. 

It was also confirmed that the error message displayed during checkout originated from Shopify’s checkout validation layer, while the root cause was related to the reward status handling in the backend reward API flow. 

The logic handling reward status updates and order processing was updated to ensure that rewards are properly validated and applied when multiple rewards are selected during checkout. 

Key Highlights 

Impact 

Summary 

Resolved an issue where the Dashboard URL incorrectly displayed the Loyalty ID instead of the Email ID when accessing member activity history. 

Overview 

An issue was identified in the member dashboard integration where the generated Dashboard URL was passing the Loyalty ID instead of the Email ID as the external identifier parameter. 

This caused inconsistencies when retrieving member activity history through the dashboard link. 

The logic has been corrected to ensure that the Email ID is passed as the external identifier in the dashboard URL, aligning with the expected API parameter behavior. 

Key Highlights 

Impact 

Summary 

Added validation for the Reward Count field in Journey configuration to prevent invalid values from being saved as Draft and later published. 

Overview 

An issue was identified in the Journey configuration where the Reward Count field within a Reward Group did not enforce validation when the journey was saved as a Draft. 

Due to the missing validation: 

• To address this issue, UI validation has been implemented for the Reward Count field during the Reward Group configuration process. 

• The validation now ensures that invalid Reward Count values cannot be saved in Draft or published. 

Key Highlights 

Impact 

Summary 

Resolved an issue in the Postgres campaign milestone sync process that triggered a New Relic error due to an undefined debit index during milestone benefit processing. 

Overview 

An error was identified in the Postgres synchronization logic for campaign milestone benefits, where the system generated a runtime warning: 

Undefined index: debit 

This occurred when a campaign milestone benefit was configured with Action ID 107, and the sync process attempted to access a debit index that was not defined in certain payload scenarios. 

As a result, the system logged errors in New Relic during campaign milestone synchronization. 

To address this issue: 

Key Highlights 

Impact 

Summary 

Resolved an issue where members appeared to be downgraded to a lower tier unexpectedly due to incorrect entries in the Tier History table. The issue was limited to display behavior and did not impact actual tier calculations. 

Overview 

An issue was reported where a member appeared to be downgraded from Birdie Tier to PAR Tier after making a purchase, despite still being within their valid tier anniversary period. 

Upon investigation, it was determined that: 

Key Highlights 

Impact 

Summary 

Completed production migration and unit testing for syncing Reward configuration additional fields with Postgres, ensuring accurate data consistency across Apps and Python services. 

Overview 

As part of the Postgres migration initiative for Rewards, additional reward configuration fields were synchronized to ensure proper data flow between the Apps layer and the Python core API. 

This update is related to prior development under LT-36521 (Sync: Reward configuration additional fields) and includes final production movement and validation. 

The following Reward components were verified during testing: 

An issue was identified during testing in the Reward Coupon Settings flow, which was traced to Python logic. The issue was debugged and resolved prior to final validation. 

Key Highlights 

 Impact 

Summary 

Updated the Rewards PATCH API to correctly handle scenarios where date fields are submitted without a timezone format. 

Overview 

An issue was identified in the Rewards PATCH API where date-time fields without an explicit timezone format were not being processed correctly. 

This caused inconsistencies when updating reward configurations, particularly for fields related to expiration or scheduling. 

The API logic has been updated to: 

The changes were validated through QA verification to ensure that reward updates function correctly across all supported date scenarios. 

Key Highlights 

Impact 

Summary 

Enhanced the synchronization of Actions and Action Groups with Postgres by adding new fields, implementing Action Group sync APIs, and aligning ADR sync services with updated schema requirements. 

Overview 

As part of the Postgres migration roadmap, updates were implemented to support synchronization of Action and Action Group configurations between MySQL, Postgres, and ADR. 

Action Group Sync 

New sync support was added for: 

A dedicated Python Sync API was created for Action Groups and integrated into the ADR sync service to ensure consistent data mapping and update flows. 

Action Table Enhancements 

The existing Action sync API for Postgres was extended to support the following new fields in the actions table: 

These fields were also implemented in ADR to maintain configuration consistency. 

Transaction Type Mapping 

Implemented synchronization between: 

This ensures accurate mapping of item type settings across databases. 

Key Highlights 

Impact 

Summary 

Updated the UAT configuration to load the TalentLMS iframe from the Production TalentLMS portal instead of the UAT instance, as per client request. 

Overview 

• As per the client’s request, the TalentLMS iframe configuration was modified to reference the Production TalentLMS portal instead of the UAT TalentLMS instance. 

• This change ensures that the UAT setup reflects live production training content and configurations from TalentLMS.  

Key Highlights 

Impact 

Summary 

Implemented Single Sign-On (SSO) enhancements for the client by integrating a new ADR version, including set-cookie functionality and domain-based redirection updates. 

Overview 

A new ADR (Authentication & Domain Routing) version was introduced to support updated authentication and redirection requirements. 

The following updates were implemented: 

• The implementation ensures seamless authentication handling and accurate domain-based routing without disrupting existing SSO workflows. 

• Full functionality testing was completed prior to release to ensure stable authentication and redirection behavior. 

Key Highlights 

Impact 

Summary 

Resolved issues related to transactional point cap enforcement and reporting discrepancies where points were exceeding the configured cap and reporting values appeared inconsistent with account-level transactional totals. 

Overview 

Two major issues were identified during review of the Interaction Report: 

Issue 1: Transactional Points Exceeding Configured Cap 

The system was allowing members to accrue transactional points beyond the configured 2,500-point cap, even though the cap was enabled. 

Root Cause: 
A product gap in how points were calculated and enforced when using hold-based earning logic allowed points to bypass the configured cap under certain scenarios. 

Resolution: 
The cap enforcement logic was updated to ensure members cannot earn more transactional points than the configured limit within the defined duration, regardless of hold type configuration. 

Issue 2: Transactional Points Appearing Double-Counted in Reports 

• Discrepancies were identified between: 

Root Cause: 
The reporting layer calculation included certain redemption and credit scenarios in a way that created apparent double-counting in report totals. 

Resolution: 
Reporting logic was corrected to ensure alignment between Interaction Reports and actual account transactional balances. 

Key Highlights 

Impact 

Summary 

Enhanced webhook events and related APIs to ensure that the actual configured Reward ID and Badge ID are returned instead of internal numeric identifiers. Added UUID support for Badge APIs and introduced consistent id parameters across Reward and Badge endpoints. 

Overview 

• An issue was identified where webhook events for external rewards were returning an internal numeric value (auto-increment table ID) instead of the actual Reward ID configured in the reward settings. 

• Similarly, Badge webhook events were not exposing a consistent identifier that aligned with API responses. 

To resolve this: 

Reward Updates 

Updated Reward Endpoints: 

Badge Updates 

This ensures consistent identifier mapping between API responses and webhook payloads. 

Key Highlights 

Impact 

Summary 

Resolved an issue where the update_date column was not being updated when points were released from hold, either manually via the Hold Points Report or automatically via a scheduled job 

Overview 

An issue was identified in the Purchase Action hold point flow, where the update_date timestamp was not being updated after hold points were released. 

This occurred in two scenarios: 

Although the points were successfully released and reflected in the member account and client's site, the update_date field in the database remained unchanged, leading to inconsistencies in tracking and auditing. 

The logic was updated to ensure that whenever hold points are released—regardless of release method—the update_date column is properly updated with the correct timestamp. 

Key Highlights 

Impact 

Summary 

Added Language Translation support to Journey API 3.1 to align with functionality already available in Journey API 3.0 and meet client requirements. 

Overview 

Journey API 3.1 previously did not support Language Translation functionality, which was already implemented in Journey API 3.0 for specific client requirements. 

To ensure feature parity and support ongoing API adoption, Language Translation capability has now been implemented in Journey API 3.1. 

The update applies translation support to: 

This enhancement is available across relevant endpoints, including: 

The implementation ensures that multilingual content configured within the system is properly returned in API responses based on language selection. 

Key Highlights 

Impact 

Summary 

Enhanced the campaign synchronization process to include additional campaign setting fields and introduced support for a new milestone bonus type (points_additional) in the sync flow between MySQL and Postgres. 

Overview 

This update improves the campaign sync mechanism by ensuring additional campaign configuration fields are properly synchronized across systems. 

New fields were added from the following MySQL tables into the sync process: 

Additionally, the milestone_bonus_type_flag field in s15_v3_campaign_detail previously supported only two values (ratio and points). This release introduces support for a new value: 

Updates were implemented in the existing  API (POST/PATCH methods) and corresponding ADR sync services to ensure proper data mapping and synchronization into Postgres. 

Key Highlights 

Impact 

Summary 

Resolved an issue where the Hold Points displayed on the dashboard did not match the Hold Points Report when the hold setting was configured as Order Item Ship Date (Action ID 109). 

Overview 

A discrepancy was identified for the Ariat client where the Hold Points shown on the dashboard differed from those in the Hold Points Report during partial shipment scenarios. 

When the hold type was set to Order Item Ship Date, and an order was partially shipped, the system behavior was inconsistent: 

Additionally, it was identified that: 

The hold points logic was updated to ensure alignment between dashboard calculations and report data. 

Key Highlights 

Impact 

Summary 

This release introduces support for Azure Blob Storage as a new connection type within DSS ADR, enabling customers to configure data feeds using Azure-based storage alongside existing options. 

Overview 

The enhancement extends ADR’s data feed configuration capabilities by adding Azure Blob Storage as a selectable connection. The implementation includes backend (Apps) and frontend (Angular) changes and has been validated across AWS and Azure environments to ensure consistent behavior. 

Key Highlights 

Impact 

Summary 

This release introduces a new Last Reward Earned Date field on the Integration Platform, providing visibility into the most recent reward earned by a member. 

Overview 

To enhance data availability for integrations and reporting, a new standard field capturing the last reward earned date has been added. 

Key Highlights 

Impact 

Summary 

This enhancement introduces a new Last Points Earned Date standard field on the Integration Platform, enabling visibility into the most recent points-earning activity for a member. 

Overview 

To improve data completeness for integrations and analytics, a new standard field capturing the last points earned date has been added to the Integration Platform. 

Key Highlights 

Impact 

Summary 

This enhancement introduces Role-Based Access Control (RBAC) for TalentLMS dashboard, allowing access to training content to be governed strictly by user roles. 

Overview 

To strengthen access control, RBAC has been implemented on the My Training page within the TalentLMS dashboard. With this update, users will only be able to view and interact with training modules that are permitted for their assigned roles. 

Key Highlights 

Impact 

Summary 

This enhancement updates the badge sorting logic to ensure badges are displayed in a consistent and expected order across the platform. 

Overview 

Previously, badge ordering could appear inconsistent in certain scenarios, leading to confusion in how badges were displayed to end users. This update refines the sorting logic and moves the corrected behavior to the production environment. 

Key Highlights 

Impact 

Summary 

Moved updated receipt scan copy changes to production for the client. 

Overview 

As part of ongoing improvements to the Receipt Scan experience for the client, content-level updates were implemented to refine and standardize the copy displayed to users. These updates focus on improving clarity and consistency without changing existing business logic or workflows. 

Key Highlights 

Impact 

• These updates improve clarity and user experience within the Receipt Scan flow for the client, ensuring clearer communication while maintaining existing functionality. 

• Receipt Scan copy updates have been deployed to production for the client to improve clarity and consistency in user-facing messaging.

Summary 

Resolved an error occurring when accessing the Earn tab on the loyalty iFrame. 

Overview 

• An issue was reported on the loyalty iFrame where users encountered an error when navigating to the Earn tab via the dashboard URL. The issue was identified during internal review and debugging sessions. 

• Investigation revealed that the error was related to TierV2 functionality, which was impacting the Earn tab rendering. The issue was analyzed across configuration and JavaScript layers, and corrective actions were implemented to ensure the Earn tab loads correctly without errors. 

 Key Highlights 

Impact 

This fix restores normal access to the Earn tab for users, ensuring uninterrupted visibility of earning opportunities within the loyalty dashboard. 

Summary