Release March 2025

Overview

We are excited to introduce the latest version of Loyalife, version 7.14, packed with new features and improvements to enhance your experience!

What's New in Version 7.14:

Manual Deletion of Reports with Fixed Timeframe Options and Storage Insights
Now reports are deleted based on the configuration done in reports
This delete is permanent(files are deleted in the storage bucket) and cant be reversed
All report types get deleted except the logs(CPD/TXN/BNS/CRD logs) present in Report section
Available/used storage information is seen on the Loyalife UI.
This delete option comes with a new permission and that would be enabled by default for admin/program admin users
Secure Member PII Data with Encryption and Decryption
1. Email Id/Mobile numbers are stored in encrypted format in the DB.
2. Also member attributes which are tagged as PI and whose data types are Number/Decimal/Date are stored in encrypted format in DB
3. All these information when sent to the customer will be in decrypted format
4. Custom attribute which is set to PI will be not be seen in reports
5. When member details are exported, in the downloaded file the data would be decrypted/Masked.
Providing ability to upload & preview transaction records from frontend
1. All file uploads which were possible only via SFTP can now be uploaded from the LBMS application
2. Max file size is now capped at 10mb.
3. All the constraints such as file name, length, data type validations etc. which were applicable in SFTP upload holds good even here
4. Error logs can be seen in Reports->logs section
5. Users with Edit platform configuration permission can only upload the files from UI
Enhancing User and Role Management for Improved Usability
1. Now user can delete the role which is not assigned to any user
2. Permissions for all the default roles (Program Admin, Program Manager, and Customer Executive) cannot be edited nor deleted.
3. Now user can view the list of permissions of role without having to edit it
4. If maker checker is enabled the user management will follow the same process
5. For existing customers/clients upgrade script needs to be run so that new permissions are updated accordingly to all the default roles.
Member Self-Service Hub
1. As part of the Loyalife Product, standard storefront is also provided.
2. Members can login as well as create new account using this storefront
3. Members have to undergo verification process via OTP to get activated. OTP template to be created in the Loyalife->Engage->communication->Transaction section
4. Member registration internally calls add member API which is customizable. But for the same to work from the storefront, UI/Form changes are required which requires Dev/QA effort.
5. Currently out of the box registration of members supports only email address, first name, last name and mobile number(optional)
6. Members can claim the transaction and do redemption (Redirected to plum store)
7. The member can view the lists of transactions in the transaction history table
8. The member can see both the credit and debit transactions in the transaction history section
9. For existing members to login to storefront, relation reference must be same as email address
  Loyalife currently supports only points in whole number. Decimals are not supported. So if any member redeems a product with different currency and due to currency conversion the redeemable points come up to decimal then LBMS will fail the redemption
Conditional Points Release Framework Post-Transaction
1. The user can set the release points with a delay by selecting the “Date attribute after which the delay begins“ and add the “Delay time before points can be used”
2. The Txn then gets processed and points would be awarded based on the rules configured. These points would be not redeemable unless the delay condition is met.
3. User can do the redemption only when the transaction type is set to 1 which marks the transaction confirmed and redeemable.
4. If a confirmed txn is redeemed and then any redemption reversal happens, it will follow the existing redemption reversal process.
Post-Transaction Points Claim Feature
1. The user can now set the Claim Points Post Transaction by selecting the “Field to Validate Purchase” and “Date Attribute”
2. The txn that land in table event_template_batch. Claim can be done by member after its available in event_template_batch.
3. Once the txn is claimed it cannot be claimed again by any other member or same member.
4. If the transaction is not claimed(which means not associated with any member) then the record will reside in the table as it is.
Remove Compulsory Issuing Points to Members for Campaigns
1. Now users can send campaigns without having to issue points
2. Rest all features of the campaign is applicable here as well
3. Features such as audience targeting insights, campaign delivery logs, and analytics for email and SMS sent are further enhanced
4. Ability to download the logs will be introduced in subsequent releases.
Extend Segments with more Attributes
1. Segments is enhanced to accommodate more filters and operators
2. User can now apply same filters multiple times while creating a segment
3. User can export and import the segment data
4. Backward compatibility is taken care to handle existing segments created in client environment. Upgrade scripts need to be run on the client environment for this to work seamlessly
5. The limitation here is that the UI wont show the filters applied but segment would run according to the filters
6. User need to manually select filters in the UI in case of existing segments.
7. User can add conflicting filters like enrolment date is within 1 days and enrolment date is not within 1 days.
8. The decimal data type will accepts the integer values only
9. Filters applied details won't show when user navigates from segment to member section.
Providing clients ability to preview of rule execution before adding a new rule
1. Member should be onboarded first for the feature to work
2. The Preview of rule engine does not take into consideration Group/Product capping feature while computing/showing the result.
3. The Preview of rule engine does not take into consideration Anomaly detection feature while computing/showing the result.
4. Preview of rule engine churns out points(Positive/negative) based on the last record present in the ET table.
5. If there are no transaction records, then user is given option to add new txn record. If txn exists, then he can still edit the transaction to suit his rule and find out rule engine output.
6. Transactions which are in pending state(Transaction type=5) also qualifies for rule preview
Customer facing API Load test for WeWork client
1. Performance benchmarking was done for the below API's which gets consumed in client's storefront
  1. Check Availability
  2. Redemption\
  3. Insert member
  4. Insert Transaction
  5. Get Member Transaction summary
  6. Complete details of the run can be seen here Loyalife Performance Benchmarking.xlsx

Functional improvements

Providing ability to send test email & sms in the communication module
1. User can now send test email/SMS before campaign/template configuration
2. This feature is tested for only Email channel due to lack of SMS account
3. Disabled templates are seen in dropdown of campaigns which existed previously as well
4. Secondary language is not supported in campaigns which is raised as an improvement and would be taken up in subsequent releases
Providing correct pending count info in Maker Checker- Action Pending emails.
1. Now user will get mail based on the pending actions he has and not w.r.t entire programs pending actions
2. All these permissions could be spread across different modules and based on that the pending mails would be sent
3. Improvement is raised so that the information shown on the email can be further enhanced GF-6861
Enhancing Reporting Feature to support Claimed and Unclaimed Transactions
New filter “Pending transaction“ is added in transaction report which allows user to see pending transaction (Transaction type=5).
These pending transactions are not seen in Accrual report(when credit by accrual or debit by reversal filter) is used.
User can export unclaimed transactions from Rule engine->Attribute setting section and this can be downloaded in Administrative data section
User with create rule engine permission is able to generate unclaimed txn report
Unclaimed transaction report and Pending Txn verified for new and existing Program
Introducing rule id & rule name in transaction view columns
Rule id, Rule name, Rule group id, Rule group name columns are now part of all kind of transactional report if selected by user.
Rule id, Rule name, Rule group id, Rule group name is showing data for all rule engine points. If we are generating the same report then we can see all columns with data.
For exported member, transactional reports show data with mentioned new columns.
For Tier Bonus, Campaign Bonus, Expiry report and Redemption the columns related to rule id, rule name will be blank
This will not apply to existing records from the old program. The Rule ID/Group will only be visible once new records are added for that program
Providing login with username and email both for non LDAP, LDAP & Cloud.
1. Now the user can login via the username or email.
2. The same is implemented for forgot password flow as well
3. If either username/email does not match or invalid details are provided then generic error message will be thrown
4. This is verified for both LDAP and Non-LDAP flows
Improving password validation for the business users
1. Now the Password strength length is configurable
2. Easily available passwords or most commonly used password are not accepted
3. Password strength Score above 3 is accepted
4. Error handling w.r.t any combination/condition not matching is addressed.
Removal of special character validation for sub-product code
1. sub-product codes can be created using hyphen (-), space ( ), underscore (_), and period (.). No other special character is allowed
2. TXN/CRD via file upload and through API works fine with these sub product codes having special characters
  Rule engine, Manual Points and other places in the application is enhanced to allow sub product codes with special characters
Partial txn refund is not working in Worldia
1. Now CR transactions will be auto claimed by the system if same txn(DR) is passed earlier is claimed by member. The claim combination parameters should be same in both DR and CR request.
2. After the claim of reversal, it will follow same computation process as that of DR txn.
3. Both CR and DR txn will be in pending state till the delay period is not reached. And once that's reached positive/negative points will be issued accordingly
4. Now there will be no cancellation (Txn type=6) as the flow is changed.
5. Partial refund/reversal will happen now based on the amount sent in CR txn. There is no check that the reversal amount should not be greater than original transaction amount.
Multi-Lingual Capabilities for Standalone Loyalty Portal
1. Now the storefront has a option to change the language based on the configuration done in weglot.
2. This was tested for French and English language based on the client's requirement. More language can be added in the weglot and the same would show up on the storefront
3. One observation noticed is that the whatever language is selected, for the first time when user does any flow the text would be seen in English and then after a second, changes to French/whichever secondary language that's configured.
Transaction API improvement
1. New option Attribute Setting is introduced in the Rule engine. Enabling this setting will allow user to pass transactions without relation reference.
2. Once the setting is made, it cannot be edited or disabled
3. Product code is mandatory field hence a dummy value has to be created and passed in the TXN API
  This is validated for existing as well as new programs
Providing manual tier update via API
1. Tier assessment is a one time configuration with Automatic or Manual as the options
2. With Manual tier setup, there will be no timeframe options
3. Following list of API's will be given to client for manual tier upgrade/downgrade
  1. Auth token
  2. GetAllTier
  3. MapMemberReferenceToTierId
  4. GetMemberTierHistoryByReference
  5. GetMemberReferencesByTierID
  6. User can map up to maximum 1000 members to tier in one request
  7. Member can be mapped to any of the tier directly but tier bonus will be issued only after execution of tier cron which needs to be called explicitly
  8. When user deletes a higher tier and those part of that tier will be downgraded to base tier at the
  9. execution of tier cron which needs to be called explicitly
    Basic API validations are implemented for all the API's
Enabling Tiers with Custom Benefits
In the default/base tier the user cannot add the bonus and point multiplier. User can add up to maximum of 10 custom benefits
When the user does not set the welcome bonus/multiplier then system by default considers welcome bonus as zero(0 points) and point multiplier as 1x
User can set the benefits sequences which has no functional relevance currently
Backward compatibility is handled i.e Tiers created in previous versions work fine with the new version as well. DB script needs to be run to make it backward compatible which is part of the release artifacts
Custom benefits feature does not have any significance as its used in storefront predominantly and hasn't been tested by QA team
All other existing features of tiers are applicable even now
Providing members ability to retain tier for x days
1. This is applicable for only rolling year time frame
2. Retention is applicable only for downgrade and not for tier upgrade
3. Minimum retention period is 30 days and maximum is 365
4. Existing features such as Maker Checker, Export Import, Aggregate attributes are handled

UI Improvements

Revamp and Standardize Program Logo Upload Process and Program Logo Placement in Loyalife Screens
Program Logo, Program Name and user logged-in information is shown on all screens.
Upload of logo is enhanced and images get auto adjusted if the dimension of the image is within the condition mentioned
If the image dimension is more than 500*500 then the image would get cropped and user needs to manually zoom in/out
Consistent Report Setup Option Across All Reporting Subsections and GF-6518: Set Default Report Retention Period to 180 Days
Cosmetic changes done w.r.t placement of Report creation CTA
Now retention period for new programs is set to 180 days . This change will not affect existing programs report setup
Showcasing pending transactions in the storefront
1. Now pending transactions are shown on the storefront
2. All pending transactions would be shown with credit Pending tag irrespective whether its positive/negative transaction since the transaction type is 1 which means Accrual
3. These pending transactions are shown only on storefront and not on Loyalife-> Member section as the requirement was for only storefront.
4. When user exports the transaction summary, even pending transaction would be shown in the report.
Changing text content in the Worldia Portal
Rendering country code in standalone portal based upon client preference
1. Label changes on storefront related to Transaction id and Particulars were done
2. New Configuration is enabled based on which the country code would be shown in storefront
3. By default, France country will be populated as that's been configured in the config file. This can be seen when user tries to register using self signup.