Release July 2025 - v7.18

1. Referral Feature

A new section called "Referral" is introduced that tracks referrals, generates unique codes, and rewards members for successful referrals.

• The Edit and View referral permissions are automatically enabled by default for Program Admins in existing programs, ensuring immediate access to referral management capabilities.
• When users manually add attributes as "Referred By" or "Referral Code" with the same data type in the manage custom attributes section, the referral setup proceeds successfully and the remaining attribute is created (the already created attribute is displayed as identical).
• However, when users add attributes as "Referred By" or "Referral Code" with different data types in the manage custom attributes section, the referral setup process will not complete successfully.
• The system introduces two new privileges in the create new role section:
  • "Edit Referral Setup": Users with this permission can create and modify referral setups
  • "View Referral Setup": Users with this permission can only view referral setup configurations
  • The "Enable Referral Program" is a one-time setup that cannot be disabled once enabled, ensuring program stability and preventing accidental deactivation.
• Users can configure referral reward conditions by selecting either "On Activation" or "On First Transaction" as the trigger mechanism.
• After referral setup completion, the system automatically creates "Referral Code" and "Referred By" custom attributes with string data type in the member attributes. These system-generated attributes cannot be edited.
• Users can pass their own referral code in CPD files/APIs, and once added, the referral code cannot be edited or updated. Users can update any member details except the referral code.
• Users cannot pass the same referral code for two different members
• Users cannot update referral codes by passing empty values via API/CPD file
• Users cannot update referral codes by passing unique referral codes via API/CPD file
• Users cannot update referral codes by passing existing member referral codes via API/CPD file

2. Redemption, Accrual & Bonus Reports to Azure Storage

• The system automatically transfers both custom and system-generated reports to Azure blob storage. However, manually generated and exported reports are excluded from this automated process to maintain user control over their specific exports.
• Only reports with active status are eligible for transfer to Azure blob storage. This ensures that data integrity is maintained and prevents the movement of files that may be in a transitional or deleted state.
• File transfers are executed through an asynchronous API that operates on a scheduled basis. The API is configured to run daily at 4:00 AM on the QA environment and has been thoroughly verified for reliability and performance.
• The transfer API accepts two key parameters:
  • Date Range Filter:
  • Start Date and End Date: These parameters filter files based on their report generation date
• Files are only transferred if they were generated within the specified date range
• If no date parameters are provided, the system defaults to the current date
  • Program ID: This parameter ensures that only files associated with the specified program are transferred
    This provides program-level isolation and data security Files are only transferred to Azure blob storage when the Minio/S3 URL is not empty, ensuring that only valid, accessible files are processed. The system demonstrates efficient transfer capabilities, with a 1GB file (compressed to 15MB) being transferred within 1 minute, ensuring timely data availability in the cloud storage.

3. Program-Level Tier Setting to Support Points, Aggregated Attribute, or Both

• The Tier Qualification Method is a new section introduced in Tier Settings that is accessible only to users with tier creation permissions. This section becomes visible and editable only after a base tier has been created and aggregate attribute conditions have been configured.
• By default, the Tier Qualification Method is set to "Point" when a new tier is created.
• System supports three tier qualification methods:
  • Point: Criteria values display as points, and member movement occurs based on points reached
  • Aggregate Attribute: Criteria values display as aggregate attribute values, and member movement occurs based on aggregate attribute values reached
  • Both: Criteria values display both points and aggregate attribute values, and member movement occurs when either points or aggregate attribute values are reached
  • When users change from one tier qualification method to another, members automatically move to appropriate tiers based on the newly selected qualification method.
  • For manual tier assessment scenarios, the tier qualification method section is not displayed, and existing functionality continues to work as before.
  • When a higher tier is deleted, members automatically downgrade to the previous tier according to the configured tier qualification method
  • The system maintains backward compatibility for existing tiers created with points and aggregate attributes:
  • Tiers with Points Only: Tier settings display qualification method as "Both" with actual points value and zero aggregate attribute value
  • Tiers with Both Points and Aggregate Attributes: Tier settings display qualification method as "Both" with actual points and aggregate attribute values
  • Tiers with Points Only (No Aggregate Attribute Configuration): Tier settings display qualification method as "Points" with actual points value and zero aggregate attribute value

4: Showcasing CRD Status on each individual

• The "Enable accounts and card linking to Members" option is a program-level setting that controls the visibility of card export functionality. This setting is exclusively available to administrators and its enable/disable status is automatically recorded in the audit trail for compliance and tracking purposes.
• The card export option is displayed to users only when the "Enable accounts and card linking to Members" feature is enabled at the program level.
• This visibility rule applies regardless of whether individual members have associated card (CRD) data or not.
• Access to card export functionality is governed by specific user permissions:
  • Export Permissions Required:
  • Users must have either "View PI" or "Create Report" permissions to export card data
  • Users without these permissions cannot initiate new card data exports
  • Users with access to the report's module can view and download previously exported reports containing card details, even if they lack export permissions.
  • This ensures that authorized users can access historical card data without requiring export privileges
  • To view card details within the member section, users must meet the following criteria:
    • "Show PI" permission
    • "View Member" permission
    • "View Member Details" permission
  • The "Enable accounts and card linking to Members" option must be enabled in the advance settings
    This multi-layered permission system ensures that sensitive card information is only accessible to appropriately authorized users while maintaining audit trails for regulatory compliance and security monitoring.

4. Rule Engine: Implement Attribute Value Grouping Feature

• The system supports comprehensive attribute group management for local attributes including Integer, String, and Selection data types.
• Users can create attribute groups through both CSV file upload and manual entry methods, providing flexibility in data input approaches.
• System Validates against empty values to maintain data quality.
• Once attribute groups are created, the system enforces data integrity by making groups non-editable and non-deletable, preventing accidental modifications that could impact existing rule configurations and member data.
• The system provides comprehensive error messaging for file upload scenarios, ensuring users receive clear feedback on validation failures, format issues, and processing errors to facilitate successful data import.
• The system validates that users receive appropriate points based on group values, ensuring that the attribute group logic correctly integrates with the points distribution system and maintains accurate member benefit calculations.
• The system allows users to add identical values across different attribute groups. Duplicate validation is specifically applied only within the same group, enabling flexible value assignment across multiple group contexts while maintaining data integrity within individual groups.
• Based on product management decisions, the system accepts all special characters in attribute values.
  As per the discussion with PM, empty values will be permitted, but only valid values will be presented in the user interface.
• The "In Group/Not In group” operator is visible to the user during rule creation for global attributes and aggregate attribute, but the rule cannot be successfully saved.

5. Member Level Capping

• When a member reaches their capping limit, they become ineligible to receive any points from all Loyalife sources including Rule Engine, Manual Points, Tier Bonus, Campaign Bonus, and Referral Bonus for the entire month.
• Any modifications to capping values made after the month has commenced will take effect in subsequent months, ensuring that changes are applied systematically without disrupting ongoing monthly calculations.
• The capping system applies comprehensively to all transaction types including credit, debit, and expired transactions. Capping enforcement is based on the processing date.
• The system supports intelligent partial point accrual when members approach their capping limits. For example, if a member has already earned 450 points and attempts to earn 100 additional points with a 500-point capping limit, only 50 points will be credited, maintaining the capping boundary.
• The platform includes sophisticated handling of negative credit transactions that can free up capping limits:
  • Example Scenario:
  • Capping limit: 1,000 points
  • Current accrued points: 900 points
  • Negative credit transaction: -500 points
  • Result: Capping limit is freed by 500 points
  • Updated status: 400 points used, 600 points available
• The system implements three distinct capping levels, and points are withheld if any of these capping mechanisms are triggered:
  • Rule Group Capping: Applies at the rule group level
  • Product Code Capping: Enforces limits at the product code level
  • Member Capping: Implements individual member-level restrictions
• When anomaly detection is enabled, the system follows a specific execution sequence:
• Capping logic executes first (Rule Group, Product Code, and Member level)
  • Points are deducted from member capping limits
  • Transaction proceeds to anomaly detection for review
  • If a transaction is rejected during anomaly detection, the points already consumed by the capping logic are not reversed, creating a permanent deduction from the member's capping allocation.

6. Tiering module linked to front end for users to see the same on Worldia which tier they are in a and target to reach on another level.
   1. A new Tier Widget has been introduced in the storefront that provides members with comprehensive information about their current tier status, next upgrade level, and the exact amount needed to reach the next tier.
   2. The Tier Widget requires the tier cron job to be executed for appropriate data to be displayed on the storefront. This cron job can be scheduled to run at different time intervals based on customer requirements. In the SaaS(Production-EU) environment, the cron is configured to run once per day.
   3. The widget's display behavior varies based on the tier configuration:
      1. Automatic Tier Setting:
         1. Members can view information about their current tier and next upgrade level
         2. Complete tier progression details are visible
      2. Manual Tier Setting:
         1. Members can only see their current tier information
         2. Next upgrade details are not displayed
   4. The Tier Widget is displayed to members only when the tier cron has been executed at least once, which places the member into a base tier. When a member registers through the storefront but the tier cron has not been executed, the Tier Widget remains hidden as the member would not be assigned to any tier (including the base tier).
   5. The system has been thoroughly tested for tier downgrade and upgrade functionality with both Lifetime and Rolling Year settings. Tier retention features with the same configurations have also been verified and confirmed to work without any issues.
   6. When Tier Retention is enabled, members can remain in a higher tier even if their current points do not match the tier conditions they belong to. This ensures that members maintain their tier benefits during the retention period, providing stability and preventing immediate downgrades based on temporary point fluctuations.
7. Enabling Editing of Member Attributes

• Users can only edit member attributes under specific conditions. Editing is permitted when:
  • The attributes are not being used in Segments, Reports, or Communication modules
  • The attributes do not contain any existing member data
• All attribute modifications are automatically logged in the audit trail, including the user who made the changes and the timestamp of the modification
• The Maker-Checker functionality does not apply to this particular feature, allowing direct attribute modifications without requiring approval workflows.
• The system allows specific constraint changes while restricting others:
  • Permitted Changes:
    • Users can change attribute constraints from mandatory to non-mandatory
    • Users can change attribute constraints from unique to non-unique
    • Users can change attribute constraints from non-unique to unique
  • Restricted Changes:
    • Users cannot change attribute constraints from non-mandatory to mandatory

8. Building Bulk Upload of Manual Points with Maker-Checker Flow

• The system only accepts specific file formats. Files uploaded in XLSX or TXT format are not supported and will be rejected.
• The uploaded file must contain all required columns as specified in the template. Files missing any mandatory columns will not be rejected.
• Files with incorrect data types will be rejected
• The system enforces a maximum limit of 1,000 records per file upload. Files containing more than 1,000 records will be rejected to maintain system performance and processing efficiency.
• If maker checker flow is enabled, the system captures all approval and rejection actions, maintaining a complete audit trail of decision-making processes for compliance and tracking purposes.
• The audit trail functionality is not currently supported for this feature and an improvement request has been raised to address this limitation.
• Users receive email notifications on successful, failed and Partial success cases
• The system has been verified to restrict access to the bulk points management feature exclusively to users who possess the "Allow Add/Remove Points in Bulk" permission.

GF-6147: 9. Providing ability to search, activate & deactivate the product code

• Users can now search for product codes using either the product name or product code identifier, and can enable or disable product codes as needed.
• When product codes are disabled, they become non-selectable across all modules in the user interface, including Manual Points, Rule Engine, Anomaly Detection, and other relevant sections.
• If a disabled product code is used in transactions, CRD files, or API calls, the system will automatically reject the record to maintain data integrity.
• The option to edit product names is exclusively available through the edit link and cannot be performed via bulk file upload, ensuring controlled modification processes.
• Users can provide duplicate product names using individual requests or bulk file uploads, but product codes must always remain unique to maintain system integrity.
• Editing product names, adding new product codes, or enabling/disabling product codes are not logged in the audit trail.
• Users can still pass disabled product codes in bulk uploads of manual points, BNS files, and BNS APIs without record rejection, providing flexibility for batch processing scenarios.
• The system performs product code enable/disable validation only at the time of request creation. For example, if a product code is enabled when a user issues manual points or receives transactions via the rule engine, and the request lands in maker checker or anomaly detection, the product code can be disabled during this stage.
• However, users can still approve or authorize the request, which will result in points being awarded.
• Users with only "View rule engine" permission cannot see product codes
• Users with "Edit rule engine" permission can enable/disable product codes, edit product names and create/upload product codes

10: Manual Segment

• A new "Manual Segment" feature has been introduced in the segment module, providing users with additional segmentation capabilities alongside the existing smart segment functionality.
• Users can create manual segments by uploading CSV files containing member data, providing flexibility for custom member groupings.
• The system supports two update modes for manual segments:
  • Append Mode:
    • Users can update manual segments by adding new member
    • The system displays counts for both existing and newly added members
  • Replace Mode:
    • Users can update manual segments by replacing existing members
    • The system displays counts for removed existing members and newly added members
  • Users can create and update segments by including members with all the statuses(Active, Inactive, Suspended, Cancelled, Blocked) available:
  • Users receive email notifications on successful, failed and Partial success cases
  • Users can delete manual segments, but deletion is restricted when the segment is actively used in campaigns, preventing accidental removal of segments in use.
  • Users can upload CSV files containing both existing and non-existing members, with existing members being successfully inserted into the segment.
  • Users with edit segment permissions can append or replace manual segment data.
  • Users with only view segment permissions cannot access manual segment upload history.
  • Manual segment CSV file uploads are not captured in the audit trail.
  • Performance Metrics
    • Small Dataset (5K members):
      • Upload time: 3.15 minutes
    • Medium Dataset (20K members):
      • Upload time: 13 minutes
    • Large Dataset (100K members):
      • Upload time: 1 hour 18 minutes

11: Review all Wording to Convert to American English

• All user-facing text has been updated to align with American English conventions (e.g., “organisation” corrected to “organization”).
• Spelling issues have been resolved across the affected modules: Member, Segment, Rule Engine, Communication and Reports.
• Labels, tooltips, button texts, field descriptions and error messages now maintain clarity throughout the UI.

12: Update the inline error message for Manual Point flow

• The maximum limit for manual points has been updated to 20 million points (20M), providing increased flexibility for high-value point transactions.
• The inline error message has been updated accordingly

13: Updates in the Worldia Transaction Table

Removal of the Description column from both the Main Transaction History section and the Transaction History table on the landing page of storefront to streamline the user interface across all transaction history views.