March 2026
10th March 2026 - 16th March 2026
Enhancement (RF-4355) |Pro Partner Resources Page Integration
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
- Added Pro Partner Resources page to site navigation.
- Integrated external resources via iframe.
- Implemented attribute-based access control for page visibility.
- Ensured navigation placement between Product Catalogue and My Account.
Impact
- Provides partners with centralized access to specialized resources.
- Ensures controlled visibility based on business role and accreditation.
- Improves user experience through seamless navigation integration.
Enhancement (LT-37555) |Webhook Trigger for Points Balance Updates via Scheduled Job
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
- Added webhook trigger logic to the loyalty rolling expiration scheduled job.
- Ensured webhook events fire when points balances are updated via scheduled processes.
- Improved consistency between system-triggered and scheduled job-triggered balance updates.
Impact
- Ensures external systems receive real-time notifications for points balance updates.
- Improves webhook reliability for integrations tracking loyalty balance changes.
- Eliminates missed events caused by scheduled job-based updates.
- Enhances synchronization between loyalty platform and downstream systems.
Enhancement (LB-5228) |Reward Report Order ID & Total Spend Population
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
- Improved Reward Report logic for Order ID population.
- Ensured Total Spend values display correctly for reward-related transactions.
- Reviewed coupon code reuse behavior and confirmed expected system behavior.
- Maintained consistent reporting behavior across reward transactions.
Impact
- Improves visibility of order-related information in Reward Reports.
- Enhances reporting accuracy for reward redemption transactions.
- Reduces confusion when analyzing reward-related order activity.
Enhancement(LB-5203) |Multiple Reward Application Issue on Shopify Checkout
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
- Fixed reward status handling during multi-reward redemption flow.
- Corrected reward validation during order API processing.
- Ensured multiple rewards can be applied successfully through the AnnexCloud Shopify widget.
- Confirmed correct interaction between reward APIs and Shopify checkout process.
Impact
- Enables users to apply multiple rewards during checkout without errors.
- Improves reward redemption experience within Shopify integrations.
- Ensures correct reward status updates during multi-reward transactions.
- Reduces checkout failures related to reward application.
3rd March 2026 - 9th March 2026
Bug Fix (INT20-12659) |Dashboard URL Showing Loyalty ID Instead of Email ID
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
- Corrected Dashboard URL parameter mapping.
- Ensured Email ID is passed as the externalID parameter instead of Loyalty ID.
- Restored proper retrieval of member activity history via the dashboard.
- Verified correct behavior with the member activity history API.
Impact
- Ensures accurate member identification in dashboard requests.
- Prevents mismatches when retrieving user activity history.
- Improves reliability of dashboard integration with the loyalty API.
Bug Fix (LB-5232) |Journey Reward Count Validation During Draft Save
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:
- Users could save the journey configuration with invalid or incomplete Reward Count values.
- The same configuration could later be published without validation, potentially causing incorrect reward logic during journey execution.
- 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
- Added validation for the Reward Count field in Journey Reward Group configuration.
- Prevented invalid Reward Count values from being saved as Draft.
- Ensured validation is enforced before publishing journeys.
- Improved consistency and reliability of Journey reward configuration.
Impact
- Prevents invalid Journey reward configurations.
- Ensures proper validation before journey publication.
- Improves stability and predictability of Journey reward execution.
- Reduces risk of misconfigured reward distribution.
Bug Fix (LT-37852) |Campaign Milestone Sync Error in Postgres
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:
Additional validation logic was implemented to ensure the debit index is checked before being accessed.
The sync process was updated to handle cases where the value is not present in the payload.
The corrected logic ensures that campaign milestone data is properly processed and synced without generating runtime errors.
Key Highlights
- Fixed undefined debit index error during campaign milestone sync.
- Improved validation checks for milestone benefit payload fields.
- Resolved New Relic runtime error triggered during sync process.
- Ensured stable synchronization for Action ID 107 milestone configurations.
Impact
- Eliminates runtime errors during campaign milestone synchronization.
- Improves stability of Postgres campaign sync processes.
- Prevents monitoring alerts caused by undefined payload fields.
- Ensures reliable milestone benefit processing across campaigns.
February 2026
24th February 2026 - 2nd March 2026
Bug Fix (LB-5208) |Incorrect Tier Downgrade Display in Tier History
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:
- The member’s actual tier calculation logic was correct.
- The issue was caused by an incorrect entry in the Tier History table.
- This created the appearance of a downgrade in reports and tier history pop-ups.
Key Highlights
- Fixed incorrect Tier History entry insertion.
- Prevented false downgrade display in Tier History popup.
- Confirmed no impact on the actual tier calculation logic.
- Validated tier behavior across purchase, return, and cancellation flows.
- Limited impact to the specific site configuration only.
Impact
- Prevents confusion caused by incorrect tier downgrade display.
- Ensures Tier History accurately represents member lifecycle.
- Maintains trust in loyalty tier progression.
- No impact to tier eligibility, anniversary logic, or rewards.
Enhancement (LT-37734) | Reward Additional Details Sync with Postgres
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:
- Reward Redemption Rules
- Reward Eligibility Rules
- Reward Eligibility Segment Mappings
- Reward Expiration Settings
- Reward Auto Redemption Rules
- Reward Notification Settings
- Reward Coupon Settings
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
- Synced Reward additional configuration fields with Postgres.
- Ensured data alignment between Apps and Python (s15-v2-core-api).
- Validated reward creation and update workflows.
- Fixed the coupon-related sync issue in the Python service.
- Completed unit testing for all related reward configuration modules.
- Confirmed correct DB mappings across reward-related tables.
Impact
- Ensures accurate Reward configuration data in Postgres.
- Prevents sync inconsistencies between Apps and backend services.
- Improves the stability of reward creation, update, and configuration flows.
- Strengthens overall Postgres migration reliability for the Rewards module.
Bug Fix (LT-37667) |Rewards PATCH API Timezone Format Handling
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:
- Properly accept date-time values without a timezone indicator.
- Normalize date inputs to the expected internal format.
- Ensure consistent handling of reward update requests regardless of timezone formatting.
The changes were validated through QA verification to ensure that reward updates function correctly across all supported date scenarios.
Key Highlights
- Fixed timezone format handling in Rewards PATCH API.
- Ensured API accepts date-time values without an explicit timezone.
- Normalized date inputs internally for consistent processing.
- Validated reward redemption and update flows after fix.
Impact
- Prevents reward update failures caused by missing timezone format.
- Improves API robustness and input flexibility.
- Ensures consistent reward configuration behavior.
- Reduces integration errors for API consumers.
Enhancement (LT-37057) | Action & Action Group Sync with Postgres
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:
Postgres Tables:
action_groups
action_group_actions
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:
expiration_type
expiration_unit
expiration_value
validate_attributes
is_item_type_multiplier_enabled
These fields were also implemented in ADR to maintain configuration consistency.
Transaction Type Mapping
Implemented synchronization between:
MySQL: s15_v3_purchase_transaction_types
Postgres: action_item_type_settings
This ensures accurate mapping of item type settings across databases.
Key Highlights
- Created Action Group and Action Group Actions sync APIs.
- Extended existing Action sync API to include new configuration fields.
- Implemented migrated ID handling for update flows.
- Resolved multiple template ID handling issues.
- Updated ADR PHP code to support Postgres payload structure.
- Ensured backward compatibility with existing Action configurations.
Impact
- Ensures complete and accurate synchronization of Action and Action Group configurations.
- Strengthens Postgres migration stability for the Loyalty module.
- Improves consistency between MySQL, Postgres, and ADR layers.
- Prevents data mismatches during Action updates and multi-template scenarios.
17th February 2026 - 23rd February 2026
Enhancement (RF-4353) | TalentLMS iFrame Source Update
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
- Updated TalentLMS iframe to use Production portal URL.
- Replaced API key to align with Production instance.
- No backend logic changes.
- No impact to platform functionality.
Impact
- Ensures the UAT reflects live TalentLMS content.
- Aligns training environment with production data.
- No changes to loyalty or platform behavior.
Enhancement (INT20-12635) | Production Log Page Design Update (Angular & Apps)
Summary
Moved and implemented updated Production Log page design changes for both Angular and Apps to align with the latest UI enhancements.
Overview
- As part of the Self Serve improvements, updates were made to the Production Log page design for both the Angular frontend and associated Apps components.
- The update involved moving and aligning the revised UI code to ensure consistency across modules and environments. The changes were focused on design and layout improvements without modifying the underlying business logic.
- No functional impact to logging behavior or backend processes was introduced.
Key Highlights
- Updated Production Log page UI design in Angular.
- Applied corresponding changes in the Apps components.
- Ensured consistent design implementation across modules.
- No backend logic changes.
Impact
- Improved UI consistency and user experience on the Production Log page.
- Enhanced maintainability of Angular and Apps code structure.
- No changes to existing logging functionality.
Enhancement (INT20-12626) |SSO Updates with New ADR Integration
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:
- Added set-cookie functionality to support the new ADR authentication flow.
- Introduced a new ADR configuration for the client-related changes.
- Updated domain-based redirection logic to ensure users are correctly routed to the new ADR.
- 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
- Integrated the new ADR version for the client.
- Implemented set-cookie handling for improved SSO session management.
- Updated domain configuration logic for accurate redirection.
- Ensured stable authentication flow across the client's sites.
- Validated functionality before production deployment.
Impact
- Improves SSO reliability and session handling.
- Ensures correct domain-based routing to the new ADR.
- Enhances authentication stability for the client users.
- Supports ongoing infrastructure and security improvements.
Bug Fix (LB-5169) |Transactional Point Cap Enforcement & Reporting Discrepancy
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:
- Earned points shown in reporting
- Actual transactional points reflected in customer accounts
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
- Fixed transactional point cap enforcement logic.
- Ensured members cannot exceed the configured 2,500-point limit.
- Corrected reporting calculations to prevent double-counting.
- Aligned Interaction Report totals with account-level data.
- Addressed the product gap related to hold-based earning logic.
- QA validated scenarios across hold types and cron-based flows.
Impact
- Ensures strict enforcement of transactional earning caps.
- Restores trust in reporting accuracy.
- Prevents unintended over-accrual of loyalty points.
- Improves financial and loyalty data consistency.
- Reduces risk of liability from over-issued points.
Enhancement (LT-37507) | Webhook External Reward & Badge ID Alignment
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 webhook payload to return the actual configured Reward ID instead of the internal table ID.
- Introduced a new id parameter in Reward APIs.
- Enabled filtering based on the id field across relevant endpoints.
Updated Reward Endpoints:
- Reward List
- User Eligible Reward List
- Reward History
- Reward Details
- Assign Reward
- Update Assign Reward
Badge Updates
- Added a new id parameter (UUID format) to Badge APIs.
- Updated webhook events to return the correct Badge identifier.
- Enabled filtering of badges based on UUID.
- Added UUID support in:
- Badge Listing API (/badges)
- User Badge API (/users/{{email_id}}/badges)
- Badge Detail endpoint
This ensures consistent identifier mapping between API responses and webhook payloads.
Key Highlights
- Webhook now returns actual configured Reward ID.
- Added id parameter to Reward APIs with filtering support.
- Introduced UUID-based id for Badge APIs.
- Updated webhook events to reflect correct Badge identifiers.
- Ensured alignment between API responses and webhook payloads.
- QA validated prior to release.
Impact
- Eliminates identifier mismatch between APIs and webhooks.
- Improves integration reliability for external systems consuming webhook events.
- Enables consistent filtering and reference handling using UUID.
- Reduces confusion caused by internal database IDs appearing in payloads.
Enhancement (LT-36894) | update_date Not Updating After Hold Points Release
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:
- Manual release of points from the Hold Points Report
- Automatic release of points via scheduled cron process
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
- Fixed update_date column not updating during manual hold release.
- Fixed update_date column not updating during cron-based release.
- Ensured timestamp consistency for Purchase Action hold criteria.
- Validated correct timestamp updates across tested user scenarios.
- Confirmed the updates remain unaffected and working correctly.
Impact
- Ensures accurate audit tracking for hold point releases.
- Improves data consistency in reporting and backend records.
- Enhances the reliability of timestamp-based reconciliation processes.
- Prevents confusion in debugging and transactional reviews.
10th February 2026 - 16th February 2026
Enhancement (LT-37295) | Journey API 3.1 Language Translation Support
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:
- Journey Name
- Journey Description
This enhancement is available across relevant endpoints, including:
- Single Journey API
- Specific Journey API
- User Journey endpoints (where applicable)
The implementation ensures that multilingual content configured within the system is properly returned in API responses based on language selection.
Key Highlights
- Added Language Translation support to Journey API 3.1.
- Aligned feature behavior with Journey API 3.0.
- Enabled translation for Journey Name and Journey Description fields.
- Applied support across all relevant Journey 3.1 endpoints.
Impact
- Ensures consistent multilingual API support across Journey API versions.
- Enables seamless migration from API 3.0 to 3.1 without feature loss.
- Supports improved customer experience for multilingual implementations.
- Meets high-priority client requirements for API adoption.
Enhancement (LT-37050) |Campaign Sync: Additional Fields & Milestone Bonus Type Update
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:
- s15_v3_campaign
- maximum_achievement_limit_value
- maximum_achievement_limit_flag
- maximum_point_limit_value
- maximum_point_limit_flag
- campaign_benefit_name
- s15_v3_campaign_detail
- maximum_achievement_limit_value
- maximum_achievement_limit_flag
- maximum_point_limit_value
- maximum_point_limit_flag
- milestone_product_id_based_bonus_flag
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:
- points_additional – required for exclude action points dropdown condition.
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
- Added new campaign setting fields to the sync process.
- Updated Python Sync API to handle additional fields in POST and PATCH methods.
- Introduced new milestone_bonus_type_flag value: points_additional.
- Updated ADR sync services to support new fields.
- Configured default values for specific fields to prevent campaign creation errors.
Impact
- Ensures complete and accurate synchronization of campaign configuration data between MySQL and Postgres.
- Supports enhanced campaign configurations with additional milestone bonus logic.
- Improves stability of campaign creation and update flows.
Bug Fix (LT-5111) |Dashboard Hold Points Mismatch with Hold Points Report
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:
- The Hold Points Report correctly retained the full hold points amount.
- The Dashboard incorrectly reduced the hold points by subtracting shipped item points, even though those points were not yet eligible for release based on the hold configuration.
Additionally, it was identified that:
- The dashboard hold points calculation did not account for discount amounts applied to orders.
- Campaign benefit hold points were not included in dashboard hold points (expected behavior, noted for clarity).
The hold points logic was updated to ensure alignment between dashboard calculations and report data.
Key Highlights
- Corrected dashboard hold points logic for Order Item Ship Date hold type.
- Ensured partial shipments do not prematurely reduce hold points on the dashboard.
- Updated logic to correctly account for discount amounts in hold points calculation.
- Maintained consistency with Hold Points Report logic.
Impact
- Ensures accurate and consistent hold points visibility across Dashboard and Hold Points Report.
- Prevents confusion caused by mismatched hold balances during partial shipments.
- Improves reporting reliability for order-based hold configurations.
- Enhances overall trust in dashboard financial metrics.
Bug Fix (LT-37450) |Webhook Points Balance Payload Alignment & Timezone Correction
Summary
Corrected the webhook points balance payload to align with the official Webhook Event Payload Documentation (v1.0.0), including fixes for group balance data structure and timezone formatting.
Overview
An issue was identified where the Points Balance webhook payload did not fully align with the documented specification for group balance fields. Additionally, the date format being sent in the payload was not consistent with the expected UTC standard.
The following corrections were implemented:
- Updated the group balance structure to match the documented schema.
- Standardized all date fields in the webhook payload to be sent in UTC format.
- Ensured payload consistency across webhook triggers.
As per the requirement, all dates are now transmitted in UTC, and any timezone conversions will be handled on the client side.
The updated payload has been validated and deployed successfully.
Key Highlights
- Aligned group balance payload structure with official documentation (v1.0.0).
- Corrected timezone formatting inconsistencies.
- Ensured all webhook date fields are sent in UTC.
- Maintained backward compatibility with existing webhook consumers.
Impact
- Ensures webhook payload compliance with documented schema.
- Prevents integration issues caused by incorrect date formatting.
- Improves consistency and reliability of webhook-based integrations.
- Enables clients to confidently handle timezone transformations on their end.
Bug Fix (LT-37336) |Loyalty Sync Issues After Postgres + Python Migration
Summary
Resolved synchronization issues in the Loyalty module following the Postgres + Python migration to ensure accurate movement of loyalty settings and feature flags to production.
Overview
As part of the Postgres + Python migration initiative for the Loyalty module, certain sync-related inconsistencies were identified when moving configurations to production.
This ticket addressed issues related to:
- Loyalty Settings synchronization
- Feature Flags synchronization
The fixes ensured that all loyalty-related configurations are correctly synced between systems and accurately reflected after migration.
Key Highlights
- Fixed sync inconsistencies in Loyalty settings after migration.
- Resolved issues affecting Feature Flags synchronization.
- Ensured smooth transition of loyalty configurations post-migration.
Impact
- Improves reliability of Loyalty configuration sync.
- Prevents configuration mismatches after migration.
- Ensures stable and consistent production behavior for loyalty features.
- Strengthens overall migration stability for Postgres + Python architecture.
3rd February 2026 - 9th February 2026
Enhancement (LS-6836) |Data Feed - Added Azure Blob Storage Connection in DSS ADR
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
- Added Azure Blob Storage as a new connection option in DSS ADR
- Implemented changes across Apps and Angular layers
Impact
- Enables customers using Azure infrastructure to integrate data feeds natively
- Improves flexibility and scalability of ADR data feed configurations
- No impact to existing data feed connections or configurations
Enhancement (INT20-12594) |Integration Platform - Added “Last Reward Earned Date” Field
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
- Added Last Reward Earned Date as a new standard field on the Integration Platform
- Field added to esp_v2_standard_loyalty_fields
Impact
- Enables partners and integrations to track the most recent reward activity
- Improves accuracy of member activity timelines and external data syncs
- No impact to existing fields, APIs, or integrations
Enhancement (INT20-12590) |Integration Platform - Added “Last Points Earned Date” Field
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
- Added Last Points Earned Date as a new standard Integration Platform field
- No changes required to existing integrations or APIs
Impact
- Enables downstream systems to identify the most recent points-earning activity
- Improves accuracy of member engagement timelines
- Supports better reporting, segmentation, and synchronization use cases
- No breaking changes or backward compatibility concerns
Enhancement (RF-4350) |Role Based Access Control for TalentLMS Dashboard
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
- Implemented Role-Based Access Control on the TalentLMS My Training dashboard
- Access to training content is now role-dependent
Impact
- Prevents unauthorized access to training content
- Improves compliance with role-based security requirements
- Enhances control over user experience within TalentLMS
- No impact on existing training data or user records
Enhancement (LT-37296) |Badge Sorting Logic
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
- Updated badge sorting logic for consistent ordering
- Ensures predictable badge display across applicable screens
- No database or schema changes required
Impact
- Improves clarity and usability of badge displays
- Eliminates inconsistencies in badge ordering
- No impact on existing badge assignments or historical data
- Safe change with minimal risk to other badge-related functionality
January 2026
27th January 2025 - 2nd February 2026
Enhancement (IMP-7869) | Receipt Scan Copy Updates
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
- Updated copy content for the Receipt Scan experience.
- No changes to receipt scan logic or validation rules.
- No database or API changes involved.
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.
Bug Fix (IMP-7849) | Earn Tab Error on iFrame
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
- Fixed the error occurring on the Earn tab in the loyalty iFrame.
- Root cause identified as TierV2-related behavior.
- No impact to other dashboard tabs or loyalty features.
Impact
This fix restores normal access to the Earn tab for users, ensuring uninterrupted visibility of earning opportunities within the loyalty dashboard.
Bug Fix (LB-5173) | Tier Not Upgrading After Order Shipment
Summary
Fixed an issue where customer tiers were not upgrading after order shipment when the Hold Type was configured as “All Items From Order Ship Date.”
Overview
When the hold configuration was set to calculate spend from the Order Ship Date, tier upgrades were not triggered immediately after shipment - even though:
- Spend was correctly reflected in APIs and reports
- Points remained on hold as expected
- Tier upgrades occurred only after a secondary action (manual release, user PATCH, or additional activity)
This behavior caused tier upgrades to be delayed and was identified as a blocker for the client.
Fix Implemented
- Tier recalculation logic has been updated to trigger immediately upon order shipment
- Spend is now correctly evaluated for tier upgrades even when points remain on hold
- No additional user activity is required for tier evaluation
- No database changes involved
Impact
- Ensures accurate and timely tier upgrades
- Removes dependency on manual actions or secondary events
- Resolves a production-blocking issue for the client
Bug Fix (LB-5172) | Interaction Report Export Blank with Source Filter
Summary
Resolved an issue where the Interaction Report export returned a blank Excel file when filtered using Action ID along with Source = “Receipt Upload”, despite data being visible in the Annex Cloud UI.
Overview
- The client reported a discrepancy between the ADR Interaction Report UI and the exported Excel file. While records were displayed correctly in the platform, exporting the same report over a larger date range resulted in an empty file.
- This behavior was reproducible in production and specifically impacted reports using source values containing spaces.
Key Highlights
- Exported Interaction Reports now match ADR UI results
- Source filters with spaces (e.g., Receipt Upload) are handled correctly
- Issue fixed for large date ranges as well
Impact
- Prevents blank exports for valid interaction data
- Restores reporting confidence for the client
- Improves consistency across reporting and export workflows
20th January 2025 - 26th January 2026
Enhancement (RF-4348) | Stat ID Added to Referral Status API
Summary
Added the stat_id field to the Referral Status API response to enable better identification of the originally referred friend.
Overview
- To support customer use cases around referral validation and signup flow personalization, the Referral Status API has been enhanced to include a new response parameter: stat_id.
- This allows customers to reliably identify the original referred friend when a referral link is shared or forwarded. The enhancement enables use cases such as pre-filling signup form data (e.g., email) and validating that the signup originates from the intended referral recipient.
- The stat_id value was already available at the database level, so no schema or DB changes were required. The API response was extended to expose this field.
Key Highlights
- Added stat_id to each referral record in the Referral Status API response.
- Enables identification of the original referral recipient even if the link is forwarded.
- Supports improved signup experiences, including email pre-fill use cases.
- No database changes required.
Impact
This enhancement improves referral tracking accuracy and enables customers to build more reliable referral validation and signup workflows without impacting existing integrations.
Bug Fix (LB-5170) | Bulk Upload: Prevent Member Creation When Toggle Is OFF
Summary
Fixed an issue where non-existing members were being created during the bulk upload process even when the Bulk Upload toggle was turned OFF.
Overview
- It has been reported that during the bulk upload process, customers who did not already exist in the system were still being created with a UID when included in the upload file, even if the bulk upload toggle was disabled in ADR.
- This behavior caused data misalignment across the client's downstream systems, where those members were not expected to exist. Although the toggle-off flow prevented opt-in and point assignment, the member record itself was still being created, which was not the intended behavior.
- The bulk upload logic has now been corrected to fully skip non-existing customers when the toggle is OFF, ensuring that no member records are created in such scenarios.
Key Highlights
- Fixed bulk upload behavior when toggle is OFF to prevent creation of non-existing members.
- Ensured only already-existing members are processed during bulk uploads.
- Prevented unintended UID creation for non-existing customers.
- Maintained existing behavior for opted-in members and retro-based setups.
Impact
This fix ensures data consistency between Annex Cloud and external systems by preventing unintended member creation during bulk uploads. It eliminates downstream mismatches, improves data governance, and aligns system behavior with customer expectations.
Bug Fix (LB-5168) | Elite Tier Not Downgrading After Attribute Reset
Summary
Fixed an issue where Elite tiers were not being downgraded after the isElite attribute was reset to No, causing customers to remain incorrectly in Elite tiers.
Overview
- It has been identified that resetting the isElite attribute to No correctly updated the attribute value but failed to recalculate and downgrade the customer’s tier accordingly. This behavior was observed primarily for Group (HM) tiers, though the underlying issue existed at the API logic level.
- As a result, affected customers continued to appear as Elite in Annex Cloud even after the attribute reset, leading to inconsistencies between attribute state, tier assignment, and downstream systems.
- The fix ensures that when the isElite attribute is reset, the tier recalculation logic is triggered correctly, and the customer is downgraded to the appropriate tier (e.g., Platinum) based on status points and configuration.
Key Highlights
- Fixed tier recalculation logic when isElite attribute is reset to No.
- Ensured Elite tiers are properly removed after attribute updates.
- Corrected behavior for Group (HM) tiers, with alignment at the API level.
- Verified and corrected impacted customer records.
Impact
This fix restores correct tier behavior for the customers by ensuring attribute-driven tier changes are accurately reflected in Annex Cloud. It prevents customers from remaining incorrectly in Elite tiers, improves data consistency across systems, and ensures reliable tier governance for both current and future updates.
Enhancement (INT20-12591) | Empty-State Message on Logs Screen
Summary
Added a clear empty-state message on the Logs screen to improve usability when no logs exist for the selected date range.
Overview
- Previously, when no logs were available for a selected date range, the Logs screen appeared blank, which could cause confusion and lead users to assume a loading or system issue.
- This enhancement introduces a user-friendly empty-state message that explicitly indicates the absence of logs for the selected period. To provide additional context and reassurance, the message also displays the last successful run timestamp along with the configured timezone.
- The change improves transparency, reduces ambiguity, and helps users quickly understand the system state without requiring further investigation or support.
Key Highlights
- Added a clear empty-state message when no logs exist for the selected date range.
- Displays the last successful run date and time, including timezone.
- Prevents blank or ambiguous UI states on the Logs screen.
Impact
This enhancement improves overall user experience and operational clarity by eliminating blank screens and providing meaningful context when no log data is available. It reduces confusion, avoids unnecessary support queries, and helps users quickly assess system activity status.
Bug Fix (IMP-7854) | Ratings & Reviews Questions
Summary
Moved updated Ratings and Reviews Questions logic to production for the client to resolve product price formatting issues.
Overview
- An issue was identified in the Ratings and Reviews Questions flow where product price values contained alphanumeric characters, leading to inconsistencies during processing and display.
- To address this, the logic was updated to sanitize product price values by removing alphanumeric characters, ensuring that only valid numeric data is processed. The fix was implemented, validated, and directly moved to the production environment as a hotfix due to its impact on live customer interactions.
Key Highlights
- Removed alphanumeric characters from product price values in Ratings & Reviews Questions.
- Ensured consistent and valid numeric price handling.
Impact
This fix ensures accurate handling of product price data in Ratings and Reviews for the client, preventing incorrect formatting issues and improving data reliability in production.
6th January 2025 - 12th January 2026
Bug Fix (LB-4993) | Correct Hold Points Display with Discounts
Summary
Resolved an issue where points on hold were displayed incorrectly when a Secondary Hold Type was configured and a discount was applied to the order.
Overview
In scenarios where a secondary hold type was enabled, the system displayed hold points based on the total order value instead of the discounted amount. This caused inconsistencies across APIs and reports, even though the Order API response showed correct values. The logic for calculating and displaying hold points was corrected to ensure discounts are properly accounted for.
Key Highlights
- Fixed hold point calculation logic for secondary hold type configurations.
- Ensured discounts are deducted correctly before calculating points on hold.
- Corrected hold points display across:
- Get Points API
- Activity API
- Order Report
- Hold Points Report
Impact
Ensures accurate and consistent visibility of points on hold when discounts are applied, improving reporting accuracy and API reliability for hold-based point workflows.
Bug Fix (LB-5089) | Reward Status Data Consistency in Reward Reports
Summary
Resolved inconsistencies between reward statuses displayed in the Annex Cloud UI and those exported via reward report CSV files, which caused mismatches in downstream data systems.
Overview
Reward status values in exported CSV files did not consistently match the statuses shown in the Annex Cloud interface. This occurred due to reward usage updates being sourced from incorrect database tables and date fields. The reward data extraction logic was updated to ensure reward usage and status changes are reflected accurately across both the UI and data exports.
Key Highlights
- Updated reward data queries to reference the correct source table for reward usage updates.
- Corrected date filtering logic to rely on reward update timestamps rather than creation timestamps.
- Ensured reward status transitions (claimed, used, expired) are consistently represented across exports and UI.
- Improved alignment of reward reporting data with downstream data ingestion platforms.
Impact
Ensures reliable and consistent reward status reporting across Annex Cloud and exported CSV files, enabling accurate tracking, reconciliation, and analytics for reward lifecycle states.