Release November 2025

1. Capture and Expose Source File Name for File-Processed Transactions and GF-9283: Enable Handback File Generation and Log Support for Bulk Points Adjustment Uploads

Now in the data exports->logs user can find the details of the bulk points adjustment.
For success, Failure and incomplete processing download option is provided for the user.
Error file will have the status and error message details along with the data uploaded by user.
The file details such as filename is also present on transaction_details_with_breakage table for only success records.
File name validation is included where system will not allow the upload if the file name is more than 50 characters.
All other features related to bulk point adjustment remains same.

2. Separate API Tokens for SSO and Redemption Rate Configuration between Loyalife and Plum and GF-9702: [BDI] Loyalife to support redemption rate configuration

Now the redemption rate configured on the Loyalife->Point definition section would be stored in the plum DB from where the storefront consumes it.
Store id has to be configured at the Loyalife services (lbms-program and lbms-maker-checker) along with proxy server configuration.
Other configuration done on Loyalife such as Cashback Rate, Customer Purchase Rate, Point terminology and currency information would not be fetched by the API.
Based on the company token, user token is created at the loyalife side which is used to push the redemption rate configuration to plum db.
Now email id has to be configured in the program and maker checker pod and this email has to be admin/super admin at the plum side to generate the user token.

3. Permission details in User Access Management export

Now Manage Team → Download under Manage Users, generates a single CSV and PDF file with the new “Permissions” column added.
The column correctly lists all permissions assigned to each user’s role(s), separated by semicolons (;).

4. Eliminate Unnecessary 0-Point Transactions When No Rule Applies

No transaction record would be created where a transaction passes through a Rule Group but no rules within the group are applicable.
When a rule applies and points computed = 0, a valid 0-point transaction record is created.
When a rule applies and points > 0, a normal transaction record is generated.

5. Rule Engine – Description Stamping Enhancement

Description Mapping checkbox is added in Points rule configuration to control transaction description behavior. When enabled, stamps rule name as the transaction description and if disabled then transaction description will be blank.
Existing rules can be modified by enabling/disabling the description mapping. Once its enabled only then the records will see the change. Past transactions already available will not undergo any change.
Description mapping option can be enabled/disabled at any point of time using edit rule option.
Info icon clarifies policy and shows red warning text when enabled.
Applies only to rules with Reward Action = Points; disabled for other reward types such as Voucher.

6. Add Session-Based Column Configuration to Total Points Accrued / Redeemed Sections

User is able to configure columns in the accrual section by selecting/deselecting the attributes.
The selection is maintained till the user logs out or changes the program.
User is able to see the data for the attributes selected and is able to reset to default without any issues.
The selection is valid only for that user persona (if any other user logs in then he will see default selection).
Redemption section is not implemented with this flow.

7. Automated Housekeeping for Transaction History (>3 Years) with Balance Summary

The bulk expiry cron job deletes transactions from the transaction details with breakage table based on their processing date and by adding +3 for Expiry Schedule.
Only records with transaction_type = 1 and transaction_type = 2 are deleted.
Pending transactions (transaction_type = 5) are excluded from deletion.
After deletion, a new summary record is created in the same table with loyalty transaction types: 50 for Accrual, 51 for Expiry, and 52 for Redemption.
In the UI, deleted records are displayed with narration as "Accrual Housekeeping", "Expiry Housekeeping", and "Redemption Housekeeping".
Transactions are deleted based on the expiration details configured in the points definition.
The expiry date is calculated at the time of each transaction based on the current point expiry period settings.
Each transaction's expiry date is determined at the time of transaction creation and remains fixed, regardless of subsequent changes to the point expiry period configuration.

8. Implement Block Code & Color Code Mapping for Debit/Credit Cards at CRD Level

If a member has only green block codes: the member can accrue rule engine points and access D-Point.
If a member has only pink/purple block codes: the member can accrue rule engine points for some block codes, cannot access D-Point, and available points cannot expire. Member status remains unchanged.
If a member has only red block codes: the member cannot accrue rule engine points, cannot access D-Point, and available points can expire. Status is changed to Cancelled member.
If a member has at least one green code along with any pink/red block codes: the member can access D-Point with the active card, and available points cannot expire. Member status remains unchanged.
If a member's green block code changes to pink block code: the member cannot access D-Point, and available points cannot expire. Member status remains unchanged.
If a member's green block code changes to red block code: the member cannot access D-Point, and available points can expire. Status is changed to Cancelled member.
When a member is in cancelled status and a new card is issued: the member must be reactivated manually by updating the status.
User should use pre processing script to remove the rows which are NO earning from the rule engine.
Green Block Codes: Credit (DM, DT, E1, F1, FM, L1, M1, O1, OB, OL, P1, Q1, Q2, Q3, R1, R2, R3, R4, U1, VP, W2, MV, W8, XY, S1, U3); Debit (3, 4, 8).
Yellow Block Codes: Debit (6, 7, 11, 12, 16, 17, 18, 19).
Orange Block Codes: Debit (1, 2, 5, 10).
Pink Block Codes: Credit (CP, CW, O3, PD, W1, W4, W6, Z4, C1, C3, C4, C5, FD).
Red Block Codes: Credit (D1, K1, J1, J2, A1, A2, A3, A4, A5, B2, B3, J3, J4, SH, TM, W5, Z1, Z5).

9. Two-Factor Authentication (2FA) – Phase 1 (Email OTP Only)

An additional layer of security to user logins is implemented using Email-based Two-Factor Authentication (2FA).
After 6 invalid OTP attempts, the user sees message "Too many invalid OTP attempts. Try again after 24 hours" as per system configuration.
After the user is locked for 24 hours and attempts to reset the password, the same message appears.
After clicking "Resend OTP" 6 times, the user receives "OTP limit reached. Please try again after 30 minutes" as per system configuration.
If a user is part of multiple programs and is archived/locked in one program, the user can still log in using two-factor authentication.
If a user is part of multiple programs and is archived/locked in all programs, the user cannot log in. However, the user will still receive the OTP.
Users can log in with either username or email address using two-factor authentication.
Users can see their username and email address masked on the two-factor authentication page.
An information icon (near the resend code button) shows how many times the OTP can be generated.
Users can see the OTP expiration timer on the screen.
Users can see a captcha on the login page. After entering the captcha, the user is redirected to the OTP screen.

10. Password Reset on Inactivity

The system redirects to the Force Password Change screen when a user logs in after N days (30) of inactivity. This is a configuration which needs to be enabled based on client requirement.
After changing the password, the user is allowed to access the dashboard.

11. Member Fetch API using Any Attribute (e.g., CIF)

With the above API, the frontend (storefront or admin panel) can fetch member details using any member attribute(custom/global).
This helps in Showing all members under a single CIF (i.e., same person with multiple cards).

12. Develop API to Fetch Member-Specific Available Offers from Active Rule Groups

New API is developed to fetch member-specific available offers from Active Rule Groups.
Rule groups are only included in the API response if the member belongs to the associated segment; members not part of the required segment will not see those rule groups in the response.
Active rule groups with valid date ranges but no active rules are excluded from the API response.
Inactive rule groups with dates outside the valid range are excluded from the API response, even if they contain active rules.

13. Kommunal - Integration of WhatsApp provided by Client on SaaS Based Loyalife (EU Instance) and Infobip Integration in WhatsApp

With this release loyalife supports Twilio/Infobip WhatsApp APIs so that campaigns and system events (similar to SMS/Email) can send out WhatsApp communications using pre-approved templates.
WhatsApp appears as a new filter option in Communication Reports alongside Email and SMS.
Users can create Transactional WhatsApp templates (text-only in Phase 1) with multiple language variants.
Users can create Promotional WhatsApp templates (text-only in Phase 1) with multiple language variants.
Users can create Promotional/Custom-Events WhatsApp templates (text-only in Phase 1) with multiple language variants.
On submission, templates go to "Pending for Approval" status until approved by Meta via Twilio Content API.
Approved templates are displayed in the UI and cannot be edited (only rejected variants are editable).
Templates with unapproved WhatsApp variants are blocked from selection in campaigns.
Users can preview WhatsApp templates the same way as email and SMS templates along with variables and their values.
Delivery Status and Retry Handling could not be tested due to developer account limitations.

14. Enhance Transaction API Response to Include Rule Details

Rule engine variables exposed in the member transaction summary (transaction table/accrual section): rule_group_id, rule_group_name, rule_name.
Rule engine attributes already exposed in transaction reports: rule_group_id, rule_group_name, rule_name, rule_id.

15. Occasion Reward Campaign in Engage

Introduced new functionality with campaign type being Occasion reward type in the campaign module.
The user can select the campaign type as occasion and sub type as either Birthday or Program anniversary.
When user select program anniversary then the user can select sub type as either Activation Date or Enrolment date.
For occasion reward type the target audience is not applicable.
Based to the campaign setup, the member will receive the bonus points.
The user can only edit the campaign name and bonus points for the occasion reward type.
Member with status "Membership blocked" will not receive the occasion reward points.
When the user creates a report with credit by bonus filter then the occasion rewards points will be generate in the report.

16. Extend Rule Engine for Voucher Issuance and GF-9147: Integrate Plum Rewards API for Marketplace Voucher Access Setup and GF-9308: Add Country-based Voucher Selection Flow in Rule Engine

The Rule Engine now supports two reward action types at the Rule Group level: Points and Voucher.
Voucher is available only if the new Marketplace integration with email and other details is present.
At the Rule Group level, users select the Reward Action (Points or Voucher) and once selected, this setting cannot be modified later.
When marketplace integration is not configured, the rule engine works based on points.
Country, voucher categories, and voucher name are fetched dynamically from the Marketplace API during rule creation.
The voucher reward preview rule is not clickable.
When a voucher/product is configured in a rule and the rule is active, if the voucher/product becomes inactive, the transaction record proceeds and logs capture "ProductId is not present" and processed lists are not received.
When a rule matches any transaction, the member receives a voucher email notification, and the transaction summary shows both the transaction record and the voucher issuance record.
For vouchers, no product code limit is applied; group limit and member limit are applied.
The voucher reward setup group cannot be exported while exporting modules.
The system displays inline validation errors when the denomination entered is out of range.
When the member email ID is empty, no voucher is issued and the system posts 0-points accrual only.
Email notifications cannot be sent to admin when vouchers become inactive (This needs to be handled by the Plum team).
The voucher list displays active/inactive/out of stock status vouchers.
The Plum Marketplace API supports only Gift cards.
Changing category clears the previous voucher selection and refreshes the voucher list.
If a rule is already active but the associated voucher becomes unavailable, vouchers cannot be issued for incoming transactions.
Users can edit voucher rules and update details.
Users can verify and approve rule engine requests for both points and voucher reward setup.
Voucher reports date appears in the "Debit by redemption" filter in the transaction reports.
Consistency between Plum and Loyalife is required as voucher issuance depends on the Plum API. If the API fails, the transaction proceeds but voucher issuance does not occur.

17. Providing HTML drag and drop editor on email communication module

GrapeJS editor integration is available in the Email Template section.
Users can drag and drop text, image, link, and button components.
Pre-built branded blocks (header, body, footer) are available.
Multilingual support for email templates is enabled.
Templates can be saved successfully after editing.
Dynamic placeholders (e.g., member_name, points_balance) are replaced with data in real time.
Preview and test-send functionality is available.
Existing templates are migrated to the new GrapeJS format. Alignment may require manual adjustment.
Variables are not auto-rendered when typing '[['; users can copy variables from the Available Variables section.
Users can upload HTML from the Add HTML section.

18. Custom Report Header Updation

Header information has been implemented in the following custom reports: Monthly Housekeeping Summary, Monthly Customer Tiering, Customer Outstanding, Monthly/Daily Custom Report for Transaction Type/Points/Amount, Monthly Cancelled Points, Monthly GL+1 Approval Summary.

19. Enhance Audit Trail for Locked/Archived User Reactivation

Audit Trail was enhanced to capture information related to reactivation of Locked/Archived users.

20. Make captcha on Login page configurable

Captcha functionality is now configurable in Loyalife through the HideCaptcha flag.
If the flag is present and its value is true, skip the captcha prompt. Otherwise, follow the existing flow.

21. Revert the Changes in the Rule engine flow- GF- 6581

Rule Engine and Attribute Setup flow has undergone change.
When a user tries to creates a rule engine, they are redirected to the attribute setup page where they can set attributes as mandatory.
Once the schema is finalized, users cannot create custom attributes with mandatory constraints.
During initial setup, product code edit, search, and disable/enable are disabled.
Users cannot create Attribute groups during initial setup.
All other functionalities remain unchanged.

22. Express Union | Add New Loyalty Transaction Type for Sports Events

The new loyalty transaction type 53 is mapped to RedemptionSportsEvent and this is a redemption transaction.
This record will not appear in the transaction report as no filter is configured. Users can use custom reports to generate the report.

23: Program-scoped “Relaxed BNS Validation” (SBM only)

LBMS now allows NULL or empty values in the product_code column of Bonus (BNS) files based on configuration.
If a program is not part of the configuration, the record will be rejected if the product code is empty for Bonus files.
No changes have been made to Bulk Points Adjustment and Rule Engine accrual, where the product code remains mandatory.
For Bonus API, regardless of whether the configuration exists or not, the product code is non-mandatory.

24: Capture Audit Log for Tier Retention Period Update

Implemented audit logging for toggle changes and value updates to the Tier Retention Period configuration in Tiers → Update Settings.
Each modification creates an Audit Trail entry that captures user actions done on tier setting page.

25: Generate Member Audit Report from Member Audit Log

New custom Report that pulls data from the existing Member → Audit Log → Member Activity.
A member attribute with bin_number (string type with Mandatory/Unique constraint set to false) must be present.
The custom report is generated monthly on the 1st of each month, and data is picked from the previous month.
The report includes fixed columns: Member ID, Bank Identifier, Activity, Date, Time, IP, Device/Browser.

26: Report File Transfer with Folder Structure - East West Bank

Based on the configuration, configured automatic generated reports are moved to Azure blob storage in a folder structure.
There is a check for file size and that should be more than 1kb.

27: Auto Activate Members when Uploaded as New

When the setting is "AUTO_ACTIVATE_NEW_MEMBERS": true, member uploaded via file would be auto activated. The member status in the CPD file should be N.
If setting is false, member would be uploaded but would not be activated automatically (status would be inactive).
Applicable only for Member upload and not for member insertion using API.

28: Hide “Reset Password” when LDAP is enabled

User will not see Change Password/reset password in any part of the loyalife application (Manage Team, Profile, Login screen, Dashboard) when LDAP is enabled.

29: Display All Validation Errors in CPD File Upload

The system now executes all validations per row instead of stopping at the first error.
Multiple validation errors for the same record are captured and displayed together in the error file, separated by semicolons (;).
Example: error_message: Duplicate Mobile_number; Invalid Gender error_code: E206;E103.

30: LBMS - Enhancement for Discount Voucher Support in Storefront Redemption

A new Additional Detail attribute has been introduced in the redemption API.
Users can pass original_amount, original_points_before_discount, discount_code, discount_value, and discount_type in JSON format.
The JSON data is stored in the Additional_Details column in the Transaction details with breakage table.

31: Remove Member-Level Uniqueness Restriction on Card Number and Account Number

The unique value restriction has been removed for the last six digits and sub-relation identifier fields.
The system will not insert the CRD if both fields have zero or empty values.

32: Add Monthly Housekeeping Summary Report for Deleted Transactions

When data is deleted from the transaction details with breakage table, a summary is created, and backup data is exported in the Administrative Data section.
The report columns include: Transaction classification, Cumulative points deleted, Execution date, and Deleted by.

33: Extend Manual Bonus Point Upload Limit from 1,000 to 30,000

Manual bonus file (bulk point adjustment) is enhanced to handle 30,000 records per file.

34: Irreversible PII Toggle Enablement

Now once the PII toggle is enabled, user will not be able to disable it.
Based on the toggle enabled/disabled the PI attributes are shown in the member attributes.

35: Implement Monthly Customer Tiering and Tiering Point Reports Based on Member Balance

The report creates buckets dynamically based on available member data.
Custom report will be executed based on the period of generation (Monthly).

36: Security Warning Copywriting – Controlled Display on Login Screen

Implemented a configurable disclaimer copy on the login screen to align with security compliance requirements.
For clients hosted on-premise or private cloud, the system displays the warning message based on configuration.
For clients hosted on public/non-private cloud, this feature is disabled entirely.

37: Add Rule Group Description Field

A Description field is available during rule group creation and update.
Entered descriptions are saved, displayed, and editable.

38: First Transaction Definition Correction

Enhanced the transaction qualification logic to apply an additional filter on loyalty_transaction_type = 1.
This ensures only transactions related to rule engine or manual point allocations are considered, excluding bonus/tier/campaign points.

39: Referral Module Access Control Enhancement - Program Manager

Enable audit trail logging for any changes in Referral Conditions and Code Generation Toggle.

40: Change int to bigint throughout database

For transaction and member custom attributes, attributes created with number/int data type are now stored as BigInt.
Applies only to newly created attributes.

41.Custom Reports created for BDI client (GF-8786, GF-8799, GF-8798, GF-8948, etc.)

Generate Monthly Custom Report for Transaction Type, Points, and Amount (supports Accruals, Reversals, Redemptions).
Customer’s Outstanding Points Report (Monthly Generation).
Monthly Cancelled Points Report (Previous month's Closed Account points).
Create Additional GL+1 Report Process with Approval Workflow.
Provide Custom Report for Miles Exchange (JAL Miles).
Generate Daily Custom Report for Transaction Type, Points, and Amount.