# Generate Auth Token Source: https://help-loyalife.xoxoday.com/api-reference/authentication/generate-auth-token POST /lbms-ingress/oauth/api/Auth/Token Exchange your Loyalife client credentials for a JWT bearer token to authenticate API calls. Loyalife uses OAuth 2.0 client credentials flow for API authentication. This endpoint exchanges your `client_id` and `client_secret` for a JWT bearer token valid for **30 minutes** (configurable). Every subsequent API call must include this token in the `Authorization` header — there is no session or cookie-based alternative. Cache the token and reuse it; never generate a new token per request. Credentials are **per-program**. Find your `client_id` and `client_secret` in Loyalife Admin under **Configurations → Program Settings → API**. Regenerating credentials immediately invalidates all previously issued tokens. ## Responses | Path | Type | Description | | ------------------------ | ------------------ | --------------------------------------------------------------------------------- | | `results.token` | string | JWT bearer token. Use as `Authorization: bearer {token}` in all subsequent calls. | | `results.tokenExpiresOn` | string (date-time) | ISO 8601 expiry timestamp. Refresh before this time. | | Path | Type | Description | | -------------------------- | ------- | ---------------------------------------------------- | | `results.IsSucessful` | boolean | `false` | | `results.ErrorCode` | string | Error code from the platform | | `results.ExceptionMessage` | string | Human-readable reason — check this field for details | *** ## Error Codes | Code | ExceptionMessage | Cause | | -------------- | ---------------- | -------------------------------------------------- | | `000` | Success | Token generated successfully | | `401` *(HTTP)* | Unauthorized | Invalid `client_id` or `client_secret` | | `999` | Bad request | Missing or malformed fields in the request payload | # API Reference Source: https://help-loyalife.xoxoday.com/api-reference/introduction Browse the complete reference for all 19 Loyalife API endpoints across 4 modules. Several behaviours in Loyalife are **configurable per program** — including points-to-currency conversion rate, token lifetime, OTP expiry duration, OTP attempt limits, redemption thresholds, and rate limits. The values documented here reflect defaults or common configurations. For the exact values that apply to your integration, contact your **Xoxoday implementation contact** or reach out to [support@xoxoday.com](mailto:support@xoxoday.com). ## Base URL All API endpoints share the same base domain: ``` https://loyalife-api.xoxoday.in ``` This is the production base URL. A **staging environment** is also available — contact your Xoxoday implementation contact for the staging URL specific to your program. ## Authentication Every endpoint (except `GenerateAuthToken` itself) requires a bearer token in the `Authorization` header: ``` Authorization: bearer {token} ``` See [Authentication](/concepts/authentication) for details on obtaining and refreshing tokens. ## Modules | Module | Path Prefix | APIs | | ------------------------ | ------------------------------- | ---- | | **OAuth / Auth** | `/lbms-ingress/oauth/` | 1 | | **Member (CPD)** | `/lbms-ingress/member/` | 9 | | **Transaction (TXN)** | `/lbms-ingress/transaction-lm/` | 6 | | **Payment Gateway (PG)** | `/lbms-ingress/pg-lm/` | 3 | ## Common Response Shape All responses use a standard envelope. See [Response Format](/concepts/response-format). ```json theme={null} { "results": { "IsSucessful": true, "ErrorCode": "000", "ExceptionMessage": "Success", "ReturnObject": { }, "Count": 0 } } ``` ## Common Parameters | Parameter | Type | Description | | ----------------------------- | ------- | -------------------------------------------------------------- | | `ProgramId` / `pintProgramId` | integer | Your loyalty program ID, issued at onboarding. | | `RelationReference` | string | The member's unique identifier (e.g. `jane.doe@example.com`). | | `RelationType` | integer | `4` = customer (used in almost all endpoints). | | `TransactionCurrency` | string | `"DEFAULT"` unless your program uses a specific currency code. | # Check Membership Credentials Source: https://help-loyalife.xoxoday.com/api-reference/members/check-credentials POST /lbms-ingress/member/api/Member/CheckMembershipCredentialsByRelationReference Enroll a new member in your loyalty program using the Loyalife Create Profile API. Validates a member's password against their stored credentials, enabling password-based login within your loyalty portal. The password must be hashed (bcrypt or MD5 depending on your program configuration) before sending — never transmit plaintext passwords. On success, the response includes the member's internal `Id` and basic profile details. For OTP-based login, use [Generate OTP by Relation Reference](/api-reference/otp/generate-otp-by-relation) → [Verify OTP by Relation Reference](/api-reference/otp/verify-otp-by-relation) instead. ## Responses | Path | Type | Description | | ------------------------------------------ | ------------------ | ------------------------------------------------------------ | | `results.IsSucessful` | boolean | `true` | | `results.ErrorCode` | string | `000` | | `results.ReturnObject.Id` | integer | Internal member ID | | `results.ReturnObject.FullName` | string | Member's full name | | `results.ReturnObject.Email` | string | Member's email address | | `results.ReturnObject.Status` | integer | Account status — `1`=Active | | `results.ReturnObject.IsAccountActivated` | boolean | Whether the account has been activated | | `results.ReturnObject.LastLoggedIn` | string (date-time) | Previous login timestamp | | `results.ReturnObject.LoginAttempt` | integer | Number of failed login attempts since last success | | `results.ReturnObject.ForceChangePassword` | boolean | `true` if the member must reset their password on next login | | Path | Type | Description | | -------------------------- | ------- | ---------------------------------------------------- | | `results.IsSucessful` | boolean | `false` | | `results.ErrorCode` | string | Error code from the platform | | `results.ExceptionMessage` | string | Human-readable reason — check this field for details | # Create Profile Source: https://help-loyalife.xoxoday.com/api-reference/members/create-profile POST /lbms-ingress/member/api/Member/CreateProfileWithAttributes Browse the complete reference for all 19 Loyalife API endpoints across 4 modules. Registers a new member in your loyalty program. The `relation_reference` you supply becomes the member's permanent identifier across all Loyalife APIs — choose it carefully (typically an email-based UUID or your internal customer ID). New members are created in `Inactive` status by default; activation happens through a separate workflow. If a member with the same `relation_reference` already exists, the API returns a `409` rather than overwriting. ## Member Status Values | Code | Status | Description | | ---- | ------------------ | ---------------------------------------------------------------------------- | | `1` | Active | Member is fully active — can earn points, redeem, and log in | | `2` | Suspended | Member account is suspended | | `3` | Login Blocked | Member cannot log in but other operations may still function | | `4` | Canceled | Member account has been canceled | | `5` | Inactive | Default state for new enrollments — member is enrolled but not yet activated | | `6` | Membership Blocked | Member's loyalty membership is blocked | Status can be managed both via API and through the Loyalife Admin portal. Any mandatory custom attributes defined in your CPD schema must also be included in the request. Optional custom attributes can also be passed. ## Responses | Path | Type | Description | | -------------------------- | ------- | ------------------------------- | | `results.IsSucessful` | boolean | `true` | | `results.ErrorCode` | string | `000` | | `results.ExceptionMessage` | string | `Success` | | `results.ReturnObject` | boolean | `true` on successful enrollment | | Path | Type | Description | | -------------------------- | ------- | ---------------------------------------------------- | | `results.IsSucessful` | boolean | `false` | | `results.ErrorCode` | string | Error code from the platform | | `results.ExceptionMessage` | string | Human-readable reason — check this field for details | *** ## Error Codes | Code | ExceptionMessage | Cause | | ------ | -------------------------------------------------- | ------------------------------------------------------- | | `000` | Success | Member enrolled successfully | | `E201` | Duplicate record | `relation_reference` already exists in this program | | `E205` | Duplicate Email: The email already exists | `email_id` is already registered to another member | | `E206` | Duplicate Mobile: The mobile number already exists | `mobile_number` is already registered to another member | | `E102` | Invalid Email | `email_id` format is invalid | | `E103` | Mandatory field missing — MRN | `relation_reference` not provided | | `E104` | Mandatory field missing — Name | `full_name` not provided | | `E105` | Mandatory field missing — Mobile Number | `mobile_number` not provided | | `E106` | Mandatory field missing — DOB | `dob` not provided | | `E107` | Mandatory field missing — Gender | `gender` not provided | | `006` | Insert failed | Data was valid but the database insertion failed | | `999` | Bad request | Malformed JSON or missing required fields | `email_id` is configured as non-mandatory for some programs (e.g. Citibank). Mandatory field codes `E103`–`E107` only fire when the field is configured as required for your program. # Get Member by Attribute Source: https://help-loyalife.xoxoday.com/api-reference/members/get-member-by-attribute GET /lbms-ingress/member/api/Member/GetMemberDetailsByUniqueAttribute Validate a Loyalife member's password for authentication via the API. Looks up a member using any unique profile attribute — such as `email_id` or `mobile_number` — when their `RelationReference` is not available. This is useful during customer support workflows or third-party integrations where only a known identifier like email is on hand. The attribute you search by must be defined in your Loyalife User schema and marked as unique; searching by non-unique fields is not supported. ## Responses | Path | Type | Description | | ---------------------------------------- | ------- | -------------------------------- | | `results.IsSucessful` | boolean | `true` | | `results.ErrorCode` | string | `000` | | `results.ReturnObject.Id` | integer | Internal member ID | | `results.ReturnObject.FullName` | string | Member's full name | | `results.ReturnObject.Email` | string | Member's email | | `results.ReturnObject.RelationReference` | string | Member's RelationReference (CID) | | `results.ReturnObject.TierName` | string | Current loyalty tier | | `results.ReturnObject.TotalPoints` | integer | Total points balance | | Path | Type | Description | | -------------------------- | ------- | ----------------- | | `results.IsSucessful` | boolean | `false` | | `results.ErrorCode` | string | Error code | | `results.ExceptionMessage` | string | Error description | # Get Member Profile Source: https://help-loyalife.xoxoday.com/api-reference/members/get-member-profile GET /lbms-ingress/member/api/Member/GetMemberProfile Look up a Loyalife member using a unique attribute, like email, when RelationReference is unknown. Returns the full profile for a member identified by their `RelationReference`. Use this to display member details, check tier status, or retrieve the internal `Id` required by [Update Profile](/api-reference/members/update-profile). If you only know the member's email or another unique attribute — not their `RelationReference` — use [Get Member by Attribute](/api-reference/members/get-member-by-attribute) instead. Query parameters must be URL-encoded before sending. For example, `jane.doe@example.com` becomes `jane.doe%40example.com`. ## Responses | Path | Type | Description | | ----------------------------------------- | ------------------ | ------------------------------------------------------------- | | `results.IsSucessful` | boolean | `true` | | `results.ErrorCode` | string | `000` | | `results.ReturnObject.Id` | integer | Internal member ID — required for Update Profile | | `results.ReturnObject.FullName` | string | Member's full name | | `results.ReturnObject.Email` | string | Member's email address | | `results.ReturnObject.MobileNumber` | string | Member's mobile number | | `results.ReturnObject.DOB` | string (date-time) | Member's date of birth | | `results.ReturnObject.Gender` | string | `M`, `F`, or `O` | | `results.ReturnObject.Address` | string | Member's address | | `results.ReturnObject.Status` | integer | Account status code — `1`=Active | | `results.ReturnObject.IsAccountActivated` | boolean | Whether the member has completed activation | | `results.ReturnObject.TierName` | string | Current loyalty tier name (e.g. `Silver`, `Gold`, `Platinum`) | | `results.ReturnObject.TotalPoints` | integer | Current points balance | | `results.ReturnObject.EnrollmentDate` | string (date-time) | Date the member was enrolled | | `results.ReturnObject.ActivatedDate` | string (date-time) | Date the member activated their account | | `results.ReturnObject.LastLoggedIn` | string (date-time) | Last login timestamp | | `results.ReturnObject.IsAccrualAllowed` | boolean | Whether the member can earn points | | `results.ReturnObject.CustomerSegment` | string | Segment assigned to the member (e.g. `DEFAULT`) | | `results.ReturnObject.PreferredLanguage` | string | Member's preferred language code (e.g. `EN`) | | `results.ReturnObject.RelationReference` | string | The member's `RelationReference` (CID) | | `results.ReturnObject.ProgramId` | integer | Program the member belongs to | | Path | Type | Description | | -------------------------- | ------- | ----------------- | | `results.IsSucessful` | boolean | `false` | | `results.ErrorCode` | string | Error code | | `results.ExceptionMessage` | string | Error description | *** ## Error Codes | Code | ExceptionMessage | Cause | | ----- | --------------------------- | --------------------------------------------------- | | `000` | Success | Member profile returned | | `103` | Member does not exist | `relation_reference` not found in the program | | `109` | Member record not available | Member exists but the record could not be retrieved | | `999` | Bad request | Missing or malformed query parameters | # Update Profile Source: https://help-loyalife.xoxoday.com/api-reference/members/update-profile POST /lbms-ingress/member/api/Member/UpdateProfileWithAttributes Update an existing Loyalife member's profile attributes via the API. Updates one or more profile fields for an existing member. Only the fields you include in the `data` object are changed — omitted fields are left unchanged. The internal `id` (not `RelationReference`) is required as the update key; obtain it from [Get Member Profile](/api-reference/members/get-member-profile) first. Custom attributes defined in your CPD schema can be updated the same way as standard fields. At least one `data.*` field must be present. Custom attributes from your CPD schema can also be included under `data`. Member status (Active, Suspended, etc.) can be managed via the Loyalife Admin portal or via API — see [Create Profile](/api-reference/members/create-profile#member-status-values) for the full status code reference. ## Responses | Path | Type | Description | | -------------------------- | ------- | --------------------------- | | `results.IsSucessful` | boolean | `true` | | `results.ErrorCode` | string | `000` | | `results.ExceptionMessage` | string | `Success` | | `results.ReturnObject` | boolean | `true` on successful update | *** ## Error Codes | Code | ExceptionMessage | Cause | | ------ | -------------------------------------------------- | --------------------------------------------------------- | | `000` | Success | Profile updated successfully | | `E202` | Member nonexistent | Member with the provided internal `id` does not exist | | `E204` | Record updation failed — cancelled member | Cannot update a cancelled member | | `E205` | Duplicate Email: The email already exists | Updated `email_id` already belongs to another member | | `E206` | Duplicate Mobile: The mobile number already exists | Updated `mobile_number` already belongs to another member | | `103` | Member does not exist | Member not found in the program | | `104` | Failed to update member profile | Update operation failed | | `113` | Member is cancelled | Member account has been cancelled | | `999` | Bad request | Malformed payload or missing internal member `id` | # Generate OTP Source: https://help-loyalife.xoxoday.com/api-reference/otp/generate-otp POST /lbms-ingress/member/api/Member/GenerateOTP Send an OTP to a member's registered channel using their email address via the Loyalife API. Triggers an OTP to be sent to a member's registered delivery channel (SMS or email, as configured for your program), identified by their email address. Use this for login, password reset, account activation, or two-factor authentication flows. The `OtpType` parameter controls which template and expiry rules apply. If you have the member's `RelationReference` (CID) rather than their email, the preferred flow is [Generate OTP by Relation Reference](/api-reference/otp/generate-otp-by-relation). ## OtpType Values | Value | Use Case | | ------------------------------ | ------------------------------------------- | | `ACTIVATION` | Account activation after registration | | `LOGIN` | Member login via OTP | | `FORGOTPWD` | Forgot password — initiate reset | | `CHANGEPASSWORD` | Change password (member is logged in) | | `RESETPASSWORD` | Reset password (admin-triggered) | | `FORGOTUSERNAME` | Forgot username recovery | | `TwoFA` | Two-factor authentication | | `UNBLOCKMEMBER` | Unblock a locked member account | | `NONE` | No specific type | | `CASHBACKCONFIRM` | Cashback transaction confirmation | | `POINTTRANSFERCONFIRM` | Points transfer confirmation | | `FAMILYPOOLINGMERGE` | Family pooling account merge confirmation | | `FAMILYPOOLINGUNMERGE` | Family pooling account unmerge confirmation | | `AIRREVIEWNCONFIRM` | Air booking review confirmation | | `DOMESTICFLIGHTREVIEWNCONFIRM` | Domestic flight booking confirmation | | `HOTELREVIEWNCONFIRM` | Hotel booking review confirmation | | `CARREVIEWNCONFIRM` | Car booking review confirmation | | `GIFTCARDREVIEWNCONFIRM` | Gift card review confirmation | | `PACKAGEREVIEWNCONFIRM` | Package booking review confirmation | | `SHOPREVIEWNCONFIRM` | Shop purchase review confirmation | | `SHOPDIGITALREVIEWNCONFIRM` | Digital shop review confirmation | | `MERCHANTREVIEWNCONFIRM` | Merchant review confirmation | | `ISPREVIEWNCONFIRM` | ISP review confirmation | | `INSURANCEREVIEWNCONFIRM` | Insurance review confirmation | OTP delivery channel (email or SMS), expiry duration, and maximum attempt limits are all **configurable at the program level** in Loyalife Admin. Confirm these values with your Xoxoday implementation contact so your UI timers and lockout handling match the actual configuration. ## Responses | Path | Type | Description | | -------------------------- | ------- | ----------------------- | | `results.IsSucessful` | boolean | `true` | | `results.ErrorCode` | string | `000` | | `results.ExceptionMessage` | string | `Success` | | `results.ReturnObject` | boolean | `true` when OTP is sent | | `results.Count` | integer | Always `0` | After a successful response, verify the OTP with [Verify OTP](/api-reference/otp/verify-otp). # Generate OTP by Relation Reference Source: https://help-loyalife.xoxoday.com/api-reference/otp/generate-otp-by-relation POST /lbms-ingress/member/api/Member/GenerateOTPByRelationReference Retrieve complete profile details for a Loyalife member using their RelationReference. Sends an OTP to a member identified by their `RelationReference` (CID). This is the preferred OTP trigger for member-facing portals where the CID is already established in your session — it avoids an extra lookup compared to the email-based flow. Loyalife routes the OTP to the member's registered channel based on their program configuration. Follow this call with [Verify OTP by Relation Reference](/api-reference/otp/verify-otp-by-relation) to complete verification. ## OtpType Values | Value | Use Case | | ------------------------------ | ------------------------------------------- | | `ACTIVATION` | Account activation after registration | | `LOGIN` | Member login via OTP | | `FORGOTPWD` | Forgot password — initiate reset | | `CHANGEPASSWORD` | Change password (member is logged in) | | `RESETPASSWORD` | Reset password (admin-triggered) | | `FORGOTUSERNAME` | Forgot username recovery | | `TwoFA` | Two-factor authentication | | `UNBLOCKMEMBER` | Unblock a locked member account | | `NONE` | No specific type | | `CASHBACKCONFIRM` | Cashback transaction confirmation | | `POINTTRANSFERCONFIRM` | Points transfer confirmation | | `FAMILYPOOLINGMERGE` | Family pooling account merge confirmation | | `FAMILYPOOLINGUNMERGE` | Family pooling account unmerge confirmation | | `AIRREVIEWNCONFIRM` | Air booking review confirmation | | `DOMESTICFLIGHTREVIEWNCONFIRM` | Domestic flight booking confirmation | | `HOTELREVIEWNCONFIRM` | Hotel booking review confirmation | | `CARREVIEWNCONFIRM` | Car booking review confirmation | | `GIFTCARDREVIEWNCONFIRM` | Gift card review confirmation | | `PACKAGEREVIEWNCONFIRM` | Package booking review confirmation | | `SHOPREVIEWNCONFIRM` | Shop purchase review confirmation | | `SHOPDIGITALREVIEWNCONFIRM` | Digital shop review confirmation | | `MERCHANTREVIEWNCONFIRM` | Merchant review confirmation | | `ISPREVIEWNCONFIRM` | ISP review confirmation | | `INSURANCEREVIEWNCONFIRM` | Insurance review confirmation | ## Responses | Path | Type | Description | | -------------------------- | ------- | ----------------------- | | `results.IsSucessful` | boolean | `true` | | `results.ErrorCode` | string | `000` | | `results.ExceptionMessage` | string | `Success` | | `results.ReturnObject` | boolean | `true` when OTP is sent | | `results.Count` | integer | Always `0` | Verify the OTP using [Verify OTP by Relation Reference](/api-reference/otp/verify-otp-by-relation). OTP expiry duration, delivery channel, and maximum attempt limits are configurable at the program level in Loyalife Admin. Confirm these values with your Xoxoday implementation contact. # Verify OTP Source: https://help-loyalife.xoxoday.com/api-reference/otp/verify-otp POST /lbms-ingress/member/api/Member/VerifyOTP Validate an email-based OTP sent via the Loyalife Generate OTP endpoint. Validates the OTP entered by the member against the one dispatched via [Generate OTP](/api-reference/otp/generate-otp). The `OtpType` must match what was used in the generate call. A successful response confirms the member's identity for the specified action (login, password reset, etc.). OTPs are time-limited and single-use. The expiry duration and maximum incorrect attempt limit are both **configurable at the program level** — confirm these values with your Xoxoday implementation contact so your UI timer and lockout handling match. A failed response means the code has expired, already been used, or the attempt limit has been reached. ## Responses | Path | Type | Description | | -------------------------- | ------- | --------------------------------- | | `results.IsSucessful` | boolean | `true` | | `results.ErrorCode` | string | `000` | | `results.ExceptionMessage` | string | `Success` | | `results.ReturnObject` | boolean | `true` on successful verification | | Path | Type | Description | | -------------------------- | ------- | ---------------------------------------------------- | | `results.IsSucessful` | boolean | `false` | | `results.ErrorCode` | string | Error code from the platform | | `results.ExceptionMessage` | string | Human-readable reason — check this field for details | # Verify OTP by Relation Reference Source: https://help-loyalife.xoxoday.com/api-reference/otp/verify-otp-by-relation POST /lbms-ingress/member/api/Member/VerifyOTPByRelationReference Validate a LOGIN OTP using a member's RelationReference via the Loyalife API. Completes the OTP verification for a member identified by their `RelationReference`. This is the second and final step of the CID-based OTP flow — call this after [Generate OTP by Relation Reference](/api-reference/otp/generate-otp-by-relation) has dispatched the code. The `OtpType` must match exactly what was used in the generate call; a mismatch will result in a failed verification even if the numeric code is correct. OTP expiry duration and maximum attempt limits are **configurable at the program level** in Loyalife Admin — confirm these values with your Xoxoday implementation contact. ## Responses | Path | Type | Description | | -------------------------- | ------- | --------------------------------- | | `results.IsSucessful` | boolean | `true` | | `results.ErrorCode` | string | `000` | | `results.ExceptionMessage` | string | `Success` | | `results.ReturnObject` | boolean | `true` on successful verification | # Check Availability Source: https://help-loyalife.xoxoday.com/api-reference/payment-gateway/check-availability POST /lbms-ingress/pg-lm/API/PG/CheckAvailability Verify a member's redeemable points balance before initiating a redemption via the Loyalife API. Queries a member's current redeemable points balance in real time. Always call this before [Redeem Points](/api-reference/payment-gateway/redeem-points) to confirm the member has sufficient balance. **Partial redemption is not supported** — members must redeem points covering the full transaction value. The points-to-currency conversion rate is configurable per program; confirm the rate for your program with your Xoxoday implementation contact to correctly calculate how many points equal the cart value. ## Responses | Path | Type | Description | | -------------------------- | ------- | -------------------------------------------------- | | `results.IsSucessful` | boolean | `true` | | `results.ErrorCode` | string | `000` | | `results.ExceptionMessage` | string | `Success` | | `results.ReturnObject` | integer | **The member's current redeemable points balance** | *** ## Error Codes | Code | ExceptionMessage | Cause | | ----- | --------------------------- | ---------------------------------------------- | | `000` | Success | Current balance returned | | `103` | Member does not exist | `RelationReference` not found in the program | | `107` | Member status is not Active | Member has not been activated | | `999` | Bad request | Missing required fields in the request payload | # Redeem Points Source: https://help-loyalife.xoxoday.com/api-reference/payment-gateway/redeem-points POST /lbms-ingress/pg-lm/API/PG/RedeemPoints Deduct points from a member's balance to complete a redemption transaction via the Loyalife API. Deducts a specified number of points from a member's balance to fulfil a redemption — for a hotel booking, flight, gift card, or charitable donation. **Partial redemption is not supported** — points must cover the full transaction value. The points-to-currency conversion rate is **configurable per program** — there is no fixed global rate. Confirm the rate with your Xoxoday implementation contact to calculate `Points` from the cart `Amount` correctly. This call is irreversible on its own; if downstream fulfilment fails after points are deducted, you must call [Reversal Points](/api-reference/payment-gateway/reversal-points) to restore the balance. Always call [Check Availability](/api-reference/payment-gateway/check-availability) first, and store the `ExternalReference` UUID returned here immediately. Save the `ExternalReference` UUID immediately. If downstream fulfillment fails, you'll need it to call [Reversal Points](/api-reference/payment-gateway/reversal-points) and restore the member's balance. ## LoyaltyTxnType Values | Value | Category | | ----- | ----------------------- | | `4` | Miles / Points Transfer | | `5` | Hotel | | `6` | Air / Flight | | `19` | Charity | | `30` | Gift Card | Additional `LoyaltyTxnType` values may be configured for your program. Use `etc.` values from your onboarding documentation if your redemption category is not listed above. ## Responses | Path | Type | Description | | -------------------------- | ------------- | --------------------------------------------------------------------------- | | `results.IsSucessful` | boolean | `true` | | `results.ErrorCode` | string | `000` | | `results.ExceptionMessage` | string | `Success` | | `results.ReturnObject` | string (UUID) | **`ExternalReference` for this transaction. Store for potential reversal.** | *** ## Error Codes | Code | ExceptionMessage | Cause | | ----- | -------------------------------- | ------------------------------------------------------ | | `000` | Success | Points deducted; redemption details in the response | | `103` | Member does not exist | `RelationReference` not found in the program | | `107` | Member status is not Active | Member has not been activated | | `113` | Member is cancelled | Member account is cancelled | | `114` | Member is suspended | Member account is suspended | | `120` | Points must be greater than zero | `Points` value is 0 or negative | | `208` | Merchant name missing | `MerchantName` not provided in the request | | `301` | Failed to redeem points | Redemption operation failed | | `302` | Insufficient points | Points requested exceed the member's available balance | | `997` | Exception occurred | Unexpected server-side error | | `999` | Bad request | Malformed payload or missing required fields | # Reversal Points Source: https://help-loyalife.xoxoday.com/api-reference/payment-gateway/reversal-points POST /lbms-ingress/pg-lm/API/PG/ReversalPoints Reverse a redemption transaction and restore the member's points balance via the Loyalife API. Cancels a previously completed redemption and restores the member's points balance. Use this when fulfilment fails after points have already been deducted — for example, a hotel booking that couldn't be confirmed, or a gift card that was not issued. Key behaviours to know: * **No time limit** — reversals can be called at any time after the original redemption, there is no expiry window. * **One reversal per transaction** — calling `ReversalPoints` a second time with the same `ExternalReference` will fail. Store the outcome of the first call. * **`ExternalReference` is required** — this UUID is the only link back to the original `RedeemPoints` transaction. If you didn't save it, the reversal cannot be processed. ## Responses | Path | Type | Description | | -------------------------- | ------- | -------------------------------------------------------- | | `results.IsSucessful` | boolean | `true` | | `results.ErrorCode` | string | `000` | | `results.ExceptionMessage` | string | `Success` | | `results.ReturnObject` | boolean | `true` when reversal is complete and points are restored | # Get Expiry Schedule Source: https://help-loyalife.xoxoday.com/api-reference/transactions/get-expiry-schedule POST /lbms-ingress/transaction-lm/API/Transaction/GetExpirySchedule Retrieve a member's periodic points expiry schedule using the Loyalife API. Returns the points expiry schedule for a member broken down by period (e.g. quarterly), showing how many points will expire at each upcoming date. Use this to surface expiry warnings in your loyalty portal — "X points expire on Dec 31" — which is one of the most effective nudges for driving redemption activity. The `Year` parameter lets you fetch future schedules for proactive campaign planning. ## Responses | Path | Type | Description | | ---------------------------------------------------------- | ------- | --------------------------------------------------------------------- | | `results.IsSucessful` | boolean | `true` | | `results.ErrorCode` | string | `000` | | `results.ReturnObject.Period` | string | Expiry period type (e.g. `Quarterly`) | | `results.ReturnObject.ExpiryPeriod[].ScheduleDate` | string | Date when this batch of points expires | | `results.ReturnObject.ExpiryPeriod[].AccrualPoints` | integer | Points accrued in this period | | `results.ReturnObject.ExpiryPeriod[].RedeemPoints` | integer | Points redeemed in this period | | `results.ReturnObject.ExpiryPeriod[].BlockedPoints` | integer | Points currently on hold/blocked | | `results.ReturnObject.ExpiryPeriod[].TotalExpiredPoints` | integer | Points that have already expired in this period | | `results.ReturnObject.ExpiryPeriod[].TotalAvailablePoints` | integer | Points still available (accrual minus redeemed, blocked, and expired) | # Get Statement Summary Source: https://help-loyalife.xoxoday.com/api-reference/transactions/get-statement-summary POST /lbms-ingress/transaction-lm/API/Transaction/GetMemberStatementSummary Retrieve a member's aggregated points balance and loyalty statement totals via the Loyalife API. Returns a member's aggregated loyalty account summary — total points earned, redeemed, expired, and the current redeemable balance. This is the primary endpoint for a loyalty wallet or dashboard screen where you want to show a member their overall standing at a glance. `ReturnObject.PointBalance` is the live redeemable balance to use in redemption eligibility checks. For a line-by-line transaction history, use [Get Transaction Summary](/api-reference/transactions/get-transaction-summary). ## Responses | Path | Type | Description | | ------------------------------------- | ------- | ---------------------------------------------- | | `results.IsSucessful` | boolean | `true` | | `results.ErrorCode` | string | `000` | | `results.ReturnObject.PointBalance` | integer | **Current redeemable points balance** | | `results.ReturnObject.Bonus` | integer | Points earned through bonus/referral campaigns | | `results.ReturnObject.Spend` | integer | Points earned through purchase transactions | | `results.ReturnObject.Redeem` | integer | Total points redeemed | | `results.ReturnObject.Partner` | integer | Points earned through partner transactions | | `results.ReturnObject.Purchased` | integer | Points purchased directly | | `results.ReturnObject.OtherAccrued` | integer | Points earned through other accrual types | | `results.ReturnObject.Air` | integer | Points redeemed for air bookings | | `results.ReturnObject.Hotel` | integer | Points redeemed for hotel bookings | | `results.ReturnObject.Car` | integer | Points redeemed for car bookings | | `results.ReturnObject.BillPayment` | integer | Points redeemed for bill payments | | `results.ReturnObject.Charity` | integer | Points donated to charity | | `results.ReturnObject.CreditTransfer` | integer | Points received via transfer | | `results.ReturnObject.DebitTransfer` | integer | Points sent via transfer | | `results.ReturnObject.ExpiredPoints` | integer | Total expired points | *** ## Error Codes | Code | ExceptionMessage | Cause | | ----- | -------------------------------------- | ---------------------------------------------------------------------------------------------- | | `000` | Success | Transaction records returned | | `009` | No records found | No transactions exist in the requested date range, or transactions have not yet been processed | | `103` | Member does not exist | `RelationReference` not found in the program | | `203` | Member statement summary not available | Statement could not be retrieved | | `204` | No transaction details available | No records match the query | | `999` | Bad request | Missing or invalid date range / pagination fields | # Get Transaction Summary by Date Source: https://help-loyalife.xoxoday.com/api-reference/transactions/get-transaction-summary POST /lbms-ingress/transaction-lm/API/Transaction/GetMemberTransactionSummaryByDate Retrieve a paginated list of a member's loyalty transactions within a specified date range. Returns a paginated list of a member's loyalty transactions within a specified date range, including points earned, redeemed, and the narration for each entry. Use this to power transaction history views in your loyalty portal or app. The `Count` field in the response gives the total matching records so you can calculate the number of pages. For an aggregated balance overview rather than individual transactions, use [Get Statement Summary](/api-reference/transactions/get-statement-summary). ## Responses | Path | Type | Description | | ------------------------------------------ | ------------- | --------------------------------------------------------- | | `results.IsSucessful` | boolean | `true` | | `results.Count` | integer | Total matching records — use for pagination | | `results.ReturnObject[].Id` | integer | Internal transaction ID | | `results.ReturnObject[].Points` | integer | Points earned or redeemed | | `results.ReturnObject[].Narration` | string | Human-readable description (e.g. `Referral Bonus`) | | `results.ReturnObject[].TransactionDate` | string | Timestamp of the original transaction | | `results.ReturnObject[].ProcessingDate` | string | Timestamp when the Rule Engine processed it | | `results.ReturnObject[].ExpiryDate` | string | When the awarded points expire | | `results.ReturnObject[].ExternalReference` | string (UUID) | Unique reference for this transaction — use for reversals | | `results.ReturnObject[].AdditionalDetail` | string | Extra context, e.g. referral source reference | | `results.ReturnObject[].LoyaltyTxnType` | integer | `1`=Spend, `2`=Earn/Bonus | | `results.ReturnObject[].MerchantName` | string | Merchant or channel name associated with the transaction | ## Pagination ``` Page 1: MinimumRange=0, MaximumRange=10 Page 2: MinimumRange=10, MaximumRange=10 Page 3: MinimumRange=20, MaximumRange=10 ``` # Insert Transaction Source: https://help-loyalife.xoxoday.com/api-reference/transactions/insert-transaction POST /lbms-ingress/transaction-lm/API/Transaction/InsertTransactionData Submit a synchronous loyalty transaction for a member using the Loyalife Insert Transaction API. Submits a single loyalty transaction and returns the result synchronously after the Loyalife Rule Engine has evaluated it. The Rule Engine automatically calculates how many points to award based on your program's configured rules — you do not specify a points amount in the request. Rules can evaluate multiple attributes including transaction `amount`, `product_code`, `transaction_type`, member tier, and any custom attributes defined in your program. If no rule matches the transaction, the transaction succeeds but zero points are awarded — `IsSucessful` will still be `true`. Use this for real-time integrations where you need the outcome before responding to the customer. For bulk or end-of-day uploads, use [Insert Transaction V2](/api-reference/transactions/insert-transaction-v2) instead. Timestamps are in the timezone of your deployment environment. For cloud deployments confirm the timezone with your Xoxoday implementation contact. For on-premise deployments, the server timezone applies. ## Responses | Path | Type | Description | | -------------------------- | ------- | ------------------------------- | | `results.IsSucessful` | boolean | `true` | | `results.ErrorCode` | string | `000` | | `results.ExceptionMessage` | string | `Success` | | `results.ReturnObject` | boolean | `true` on successful submission | | Path | Type | Description | | -------------------------- | ------- | ---------------------------------------------------------------------------- | | `results.IsSucessful` | boolean | `false` | | `results.ErrorCode` | string | Error code from the platform | | `results.ExceptionMessage` | string | Human-readable reason, e.g. `Invalid product code` — always check this field | *** ## Error Codes | Code | ExceptionMessage | Cause | | ----- | ---------------------------------- | ---------------------------------------------------------- | | `000` | Success | Transaction accepted and queued for Rule Engine processing | | `006` | Insert failed | Transaction could not be inserted | | `103` | Member does not exist | `member_relation_reference` not found in the program | | `201` | Failed to award points | Points calculation or award step failed | | `209` | Transaction reference missing | `transaction_id` not provided | | `210` | Request DateTime invalid / missing | `transaction_date` is missing or in the wrong format | | `997` | Exception occurred | Unexpected server-side error | | `999` | Bad request | Malformed payload or missing required fields | # Insert Transaction V2 (Batch) Source: https://help-loyalife.xoxoday.com/api-reference/transactions/insert-transaction-v2 POST /lbms-ingress/transaction-lm/API/Transaction/InsertTransactionDataV2 Submit one or more Loyalife transactions asynchronously for bulk, high-volume processing. Accepts an array of loyalty transactions and queues them for asynchronous processing by the Rule Engine. The Rule Engine automatically calculates points for each transaction based on your program rules — you do not specify points amounts. The API returns immediately with a `batch_id`; processing happens in the background. There is currently **no enforced batch size limit**, but keeping batches under **100 transactions** is strongly recommended for performance. A batch size limit of 100 may be enforced in a future release. Timestamps are in the timezone of your deployment environment. For cloud deployments confirm the timezone with your Xoxoday implementation contact. For on-premise deployments, the server timezone applies. `transaction_id` is **not** deduplicated server-side by default. Use `_xoxo_api_client_idempotency` for safe retries — reuse the same value when retrying, generate a new one only for a genuinely new submission. See [Idempotency](/concepts/idempotency). ## Responses | Path | Type | Description | | --------------------------------------------------------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------ | | `results.IsSucessful` | boolean | `true` | | `results.ErrorCode` | string | `001` — note: this endpoint returns `001` (not `000`) on success | | `results.ExceptionMessage` | string | `Success` | | `results.ReturnObject.batch_id` | string | Identifies this batch — e.g. `abc_1759321530_123`. Pass to [Poll Batch Status](/api-reference/transactions/poll-batch-status). | | `results.ReturnObject.message` | string | `Transactions queued successfully` | | `results.ReturnObject.total_transactions` | integer | Number of transactions accepted into the batch | | `results.ReturnObject.transactions` | array | One entry per transaction submitted in the batch | | `results.ReturnObject.transactions[].member_relation_reference` | string | The member identifier from the request | | `results.ReturnObject.transactions[].transaction_id` | string | The `transaction_id` from the request | | `results.ReturnObject.transactions[].transaction_type` | string | `dr` (debit / earn) or `cr` (credit / reversal) | | `results.ReturnObject.transactions[].request_id` | string | Server-assigned unique ID for this queued item — use for support or tracing | ```json theme={null} { "results": { "IsSucessful": true, "ErrorCode": "001", "ExceptionMessage": "Success", "ReturnObject": { "batch_id": "abc_1759321530_123", "message": "Transactions queued successfully", "total_transactions": 3, "transactions": [ { "member_relation_reference": "M00001", "transaction_id": "TXN-1001", "transaction_type": "dr", "request_id": "req_a1b2c3d4..." }, { "member_relation_reference": "M00001", "transaction_id": "TXN-1001", "transaction_type": "cr", "request_id": "req_e5f6g7h8..." }, { "member_relation_reference": "M00002", "transaction_id": "TXN-1002", "transaction_type": "dr", "request_id": "req_i9j0k1l2..." } ] } } } ``` # Poll Batch Status Source: https://help-loyalife.xoxoday.com/api-reference/transactions/poll-batch-status GET /lbms-ingress/transaction-lm/API/Transaction/PollTransactionBatchStatus Check the processing status of a transaction batch submitted via the Insert Transaction V2 API. Checks the processing status of a transaction batch submitted via [Insert Transaction V2](/api-reference/transactions/insert-transaction-v2). Since V2 processing is asynchronous, your system must poll this endpoint until `summary.pending` reaches `0` to confirm all transactions have been evaluated. The response includes per-item outcomes so you can identify and handle any failures or holds individually. Use exponential backoff when polling to avoid rate limits. ## Responses | Path | Type | Description | | ------------------------------------------- | ------- | ----------------------------------------------------------------- | | `results.IsSucessful` | boolean | `true` | | `results.ReturnObject.batch_id` | string | The batch UUID | | `results.ReturnObject.summary.total` | integer | Total transactions in batch | | `results.ReturnObject.summary.success` | integer | Successfully processed | | `results.ReturnObject.summary.failed` | integer | Failed count | | `results.ReturnObject.summary.pending` | integer | Still processing — keep polling while `> 0` | | `results.ReturnObject.summary.on_hold` | integer | Held for review | | `results.ReturnObject.summary.partial_hold` | integer | Partially awarded, remainder on hold | | `results.ReturnObject.results[].request_id` | string | Per-transaction reference | | `results.ReturnObject.results[].status` | string | `SUCCESS` \| `FAILED` \| `ON HOLD` \| `PARTIAL HOLD` \| `PENDING` | | `results.ReturnObject.results[].points` | integer | Points awarded — present for `SUCCESS` and `PARTIAL HOLD` | | `results.ReturnObject.results[].message` | string | Human-readable status message | | `results.ReturnObject.results[].error` | string | Error reason — present for `FAILED` only | ## Per-Item Status Values | Status | Fields Present | Meaning | | -------------- | ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `SUCCESS` | `points`, `message` | Fully processed. `points` reflects the awarded amount. | | `FAILED` | `error` | Processing failed. `error` contains the reason — check program logs for the `request_id`. | | `ON HOLD` | `message` | The **Points Hold** feature or an **Anomaly Detection** threshold is configured for your program. No points are awarded until the hold is reviewed and released in Loyalife Admin. | | `PARTIAL HOLD` | `points`, `message` | A transaction generated multiple reward events. Some were awarded immediately (`points` reflects those); the remainder are held because Points Hold or Anomaly Detection is active. Held rewards release after admin review. | | `PENDING` | `message` | Still processing. Poll again — use exponential backoff until no items remain in `PENDING`. | Keep polling until `summary.pending === 0`. Items in `PENDING` state are not yet finalized. # Authentication Source: https://help-loyalife.xoxoday.com/concepts/authentication Learn how to authenticate with the Loyalife API using OAuth 2.0 client credentials. ## Overview Loyalife uses **OAuth 2.0 client credentials flow**. You exchange your `client_id` and `client_secret` for a short-lived JWT bearer token. Every subsequent API call must include this token in the `Authorization` header. ``` Authorization: bearer {token} ``` ## Getting Your Credentials Credentials are **per-program** — each loyalty program has its own distinct `client_id` and `client_secret`. To find yours: 1. Log in to the Loyalife Admin portal 2. Navigate to **Configurations → Program Settings → API** 3. Copy the **Client ID** and **Secret ID** If you need to regenerate credentials (e.g. after a security incident), use the **Reset Client and Secret ID** option on the same page. This immediately invalidates all tokens issued with the previous credentials — update your integration before regenerating. ## Token Lifetime Tokens are valid for **30 minutes** by default. The exact expiry is in the `tokenExpiresOn` field of the auth response. Token lifetime is configurable at the environment level — confirm with your Xoxoday implementation contact if a different value applies. Your integration should: 1. Cache the token and reuse it across requests until it expires. 2. Proactively refresh before `tokenExpiresOn`, or reactively on receiving a `401`. 3. Never generate a new token per request — this is wasteful and will approach rate limits faster. ## Environments Both **production** and **staging** environments are available. Contact your Xoxoday implementation contact to get the staging base URL for your program. Test against staging before going live. ## Scopes The `scope` field is optional. Omit it for a general-purpose program token. To bind a token to a specific member (for member-level operations like OTP login): ```json theme={null} { "scope": "[\"LOGIN\",\"jane.doe@example.com\"]" } ``` When scope is omitted, the token can be used for all member operations under your program. ## Rate Limits Rate limits are configurable per `client_id`. The specific limits and the HTTP status returned when exceeded depend on your program configuration — confirm with your Xoxoday implementation contact. ## IP Whitelisting IP whitelisting is **not required**. The APIs can be called from any server. Always call from a backend server — never expose credentials or make API calls from client-side code (browser or mobile app). ## Error Responses All APIs return a consistent error structure: ```json theme={null} { "results": { "IsSucessful": false, "ErrorCode": "1484", "ExceptionMessage": "Human-readable reason" } } ``` The API returns actual HTTP status codes alongside this body: * `401` — Token expired or invalid credentials * `400` — Malformed or invalid request * `200` with `IsSucessful: false` — Request was structurally valid but failed business logic (e.g. member not found, OTP mismatch) Always read `ExceptionMessage` — it is the most reliable field for diagnosing the specific failure. ## Security Notes * Never expose `client_secret` or bearer tokens in client-side code, logs, or version control. * Always use HTTPS in production. * Rotate credentials immediately if compromised — use **Reset Client and Secret ID** in Loyalife Admin. # Idempotency Source: https://help-loyalife.xoxoday.com/concepts/idempotency Learn how to safely retry Loyalife transaction submissions without risking duplicate processing. ## Why Idempotency Matters Network timeouts and ambiguous responses are unavoidable. Without idempotency, retrying a failed request can result in the same transaction being processed twice — awarding duplicate loyalty points. Loyalife's transaction APIs support client-controlled idempotency via the `_xoxo_api_client_idempotency` field. ## How It Works ```json theme={null} { "_xoxo_api_client_idempotency": "order-invoice-2026-00123", "transaction_id": "TXN-2026-00123", "amount": 500, ... } ``` * **Generate once per logical submission** — use an ID tied to the business event (e.g. purchase order ID, invoice ID, or a UUID you generate once for each intended processing attempt). * **Reuse on retries** — if the first submission times out or returns an ambiguous response, retry with the **same** `_xoxo_api_client_idempotency`. The platform will recognise the duplicate and not process it twice. * **Generate a new ID for new submissions** — only generate a new `_xoxo_api_client_idempotency` when you genuinely intend a new business transaction. ## `transaction_id` vs `_xoxo_api_client_idempotency` | Field | Enforced as unique by LBMS? | Purpose | | ------------------------------ | --------------------------- | ------------------------------------------------------------------------ | | `transaction_id` | No | Your business identifier for the row — used for your own reconciliation. | | `_xoxo_api_client_idempotency` | Program-dependent | Safe retry key — prevents double-processing on retries. | LBMS does **not** enforce global uniqueness on `transaction_id`. If your processes require uniqueness, enforce it on your side. Confirm with your Xoxoday implementation contact whether `_xoxo_api_client_idempotency` is mapped to a unique column in your program configuration. ## Integration Checklist Create a stable, unique key per logical business request — e.g. the purchase order ID. Include `_xoxo_api_client_idempotency` in the request body. Reuse the **same** `_xoxo_api_client_idempotency`. Do not generate a new one. Use [Poll Batch Status](/api-reference/transactions/poll-batch-status) to confirm the outcome of a V2 batch submission. # Response Format Source: https://help-loyalife.xoxoday.com/concepts/response-format Learn the standard JSON envelope structure shared by every Loyalife API response. ## Standard Envelope Every Loyalife API response wraps its payload in a `results` object: ```json theme={null} { "results": { "IsSucessful": true, "ErrorCode": "000", "ExceptionMessage": "Success", "ReturnObject": { ... }, "Count": 0 } } ``` `IsSucessful` is spelled with one "s" — this matches the service's actual response field name. ## Fields | Field | Type | Description | | ------------------ | ------- | --------------------------------------------------------------------------------------- | | `IsSucessful` | boolean | `true` if the request was processed successfully. | | `ErrorCode` | string | `"000"` on success. A non-zero code indicates an error. | | `ExceptionMessage` | string | `"Success"` on success; error description on failure. | | `ReturnObject` | any | The response payload — varies by endpoint. May be an object, array, boolean, or scalar. | | `Count` | integer | Number of records returned (used on list endpoints). | ## Success Response ```json theme={null} { "results": { "IsSucessful": true, "ErrorCode": "000", "ExceptionMessage": "Success", "ReturnObject": true, "Count": 0 } } ``` ## Error Response ```json theme={null} { "results": { "IsSucessful": false, "ErrorCode": "E001", "ExceptionMessage": "Member not found", "ReturnObject": null, "Count": 0 } } ``` ## Checking for Errors Always check `IsSucessful` first — the HTTP status code alone is not sufficient. A `200 OK` response can still contain `IsSucessful: false` when the request was received but the business logic failed. ```python theme={null} response = requests.post(url, ...) data = response.json()["results"] if not data["IsSucessful"]: raise Exception(f"API error {data['ErrorCode']}: {data['ExceptionMessage']}") return data["ReturnObject"] ``` *** ## Universal Error Codes These codes may be returned by **any** API endpoint. | Code | ExceptionMessage | Meaning | | ----- | ------------------ | -------------------------------------------------------------- | | `000` | Success | Request succeeded | | `997` | Exception occurred | Unexpected server-side error | | `998` | Invalid request | Request is structurally invalid | | `999` | Bad request | Payload not constructed properly — missing or malformed fields | ## HTTP Transport Codes These are standard HTTP status codes returned at the transport layer, separate from the `ErrorCode` field in the envelope. | HTTP Status | Meaning | | ----------- | ---------------------------------------------- | | `400` | Bad request — malformed payload | | `401` | Unauthorized — missing or expired Bearer token | | `500` | Internal server error | | `501–503` | Server down / gateway unavailable | A `200 OK` HTTP response does not guarantee success. Always check `IsSucessful` in the response envelope — business logic errors return `200` with `IsSucessful: false` and a non-zero `ErrorCode`. # Xoxoday Documentation Source: https://help-loyalife.xoxoday.com/home Guides, references, and walkthroughs for every Xoxoday product — Empuls, Plum, and Loyalife.
Xoxoday Xoxoday

Xoxoday's product suite

Get a comprehensive view of the products offered by Xoxoday and their key features — for admins and end users alike.

Search… ⌘K

Browse by product

Pick a product to jump into its guides.

Empuls Empuls

Employee engagement, recognition and rewards, surveys, and the social intranet.

Popular guides
Log in to Empuls→ Set up awards→ Run a pulse survey→ Explore all docs →
Plum Plum

Rewards, incentives, and payouts infrastructure — gift cards and digital rewards.

Popular guides
Redeem reward points→ Fund your account→ Send reward links→ Explore all docs →
Loyalife Loyalife

Build and run loyalty programs — tiers, points, and member engagement.

Popular guides
Accessing Loyalife→ Members overview→ Rule Engine overview→ Explore all docs →

Get more from Xoxoday

Updates, walkthroughs, and support whenever you need them.

Product updates
What's new across the platform.
User guides
Set up and run your loyalty program.
Raise a ticket
Reach the Xoxoday customer success team.
Privacy Policy Terms of Service Cookie Policy

© 2026 Xoxoday, Inc. · Make every day rewarding.

Xoxoday Xoxoday
# Quickstart Source: https://help-loyalife.xoxoday.com/quickstart Follow this quickstart guide to make your first Loyalife API call in under 5 minutes. ## Prerequisites Before you begin, obtain the following from your Xoxoday onboarding pack: | Credential | Description | | --------------- | ------------------------------------------- | | `client_id` | Your OAuth client ID | | `client_secret` | Your OAuth client secret | | `ProgramId` | Your loyalty program ID (e.g. `19`) | | `domain` | API domain (e.g. `loyalife-api.xoxoday.in`) | Never commit `client_secret` or bearer tokens to source control. ## Step 1 — Generate an Auth Token All API calls require a bearer token. Generate one using your client credentials: ```bash cURL theme={null} curl --request POST \ --url https://{domain}/lbms-ingress/oauth/api/Auth/Token \ --header 'Content-Type: application/json' \ --header 'Accept: application/json' \ --data '{ "grant_type": "client_credentials", "client_id": "{client_id}", "client_secret": "{client_secret}", "scope": "[\"LOGIN\",\"{RelationReference}\"]" }' ``` ```python Python theme={null} import requests response = requests.post( "https://{domain}/lbms-ingress/oauth/api/Auth/Token", headers={"Content-Type": "application/json", "Accept": "application/json"}, json={ "grant_type": "client_credentials", "client_id": "{client_id}", "client_secret": "{client_secret}", "scope": '["LOGIN","{RelationReference}"]' } ) token = response.json()["results"]["token"] ``` ```javascript Node.js theme={null} const response = await fetch( `https://{domain}/lbms-ingress/oauth/api/Auth/Token`, { method: "POST", headers: { "Content-Type": "application/json", "Accept": "application/json" }, body: JSON.stringify({ grant_type: "client_credentials", client_id: "{client_id}", client_secret: "{client_secret}", scope: '["LOGIN","{RelationReference}"]' }) } ); const { results } = await response.json(); const token = results.token; ``` **Response** ```json theme={null} { "results": { "token": "eyJhbGci...", "tokenExpiresOn": "2026-03-16T15:15:02Z" } } ``` Save the `token` value — use it as `Authorization: bearer {token}` in all subsequent calls. ## Step 2 — Enroll a Member ```bash cURL theme={null} curl --request POST \ --url 'https://{domain}/lbms-ingress/member/api/Member/CreateProfileWithAttributes?pintProgramId={ProgramId}' \ --header 'Authorization: bearer {token}' \ --header 'Content-Type: application/json' \ --data '{ "relation_reference": "jane.doe@example.com", "full_name": "Jane Doe", "email_id": "jane.doe@example.com", "mobile_number": "+919876543210", "status": "5" }' ``` ## Step 3 — Submit a Transaction ```bash cURL theme={null} curl --request POST \ --url 'https://{domain}/lbms-ingress/transaction-lm/API/Transaction/InsertTransactionData?pintProgramId={ProgramId}' \ --header 'Authorization: bearer {token}' \ --header 'Content-Type: application/json' \ --data '{ "transaction_id": "TXN-001", "amount": 500, "transaction_date": "2026-05-11", "product_code": "RETAIL001", "member_relation_reference": "jane.doe@example.com", "transaction_type": "DR" }' ``` ## Step 4 — Check Points Balance ```bash cURL theme={null} curl --request POST \ --url 'https://{domain}/lbms-ingress/transaction-lm/API/Transaction/GetMemberStatementSummary' \ --header 'Authorization: bearer {token}' \ --header 'Content-Type: application/json' \ --data '{ "RelationReference": "jane.doe@example.com", "TransactionCurrency": "DEFAULT", "RelationType": 4, "ProgramId": {ProgramId} }' ``` ## Next Steps Submit multiple transactions asynchronously as a batch. Initiate a points redemption for a member. # Release Notes Source: https://help-loyalife.xoxoday.com/release-notes/index Browse Loyalife's complete version history — track new features, improvements, and changes across every release. # Release Notes Stay up to date with every Loyalife release. Each entry covers new features, improvements, and notable changes shipped in that version. | Version | Release | Highlights | | ------------------------------- | ---------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [v7.25.0](/release-notes/v7-25) | June & July 2026 | SAML SSO, custom branded mobile app UI, configurable aggregate computation timing, AG Grid custom reports, push in campaigns, V2 realtime API improvements, rule engine operators, segment redesign | | [v7.24.0](/release-notes/v7-24) | March 2026 | SFTP multi-destination routing, billing cycle flexibility, real-time report view, AppsFlyer referral integration | | [v7.23](/release-notes/v7-23) | February 2026 | Decimal point calculations, new custom reports (Expiry, Projected Expiry, Admin Audit), SHA-256 BDI encryption | | [v7.22](/release-notes/v7-22) | December 2025 | Skipped-tier bonus awards, 15-language support, preferred language for communications, points expiry visibility | | [v7.21](/release-notes/v7-21) | November 2025 | Pay with Rewards APIs, cashback processing, six new custom reports, DateTime format support | | [v7.20](/release-notes/v7-20) | November 2025 | Email OTP 2FA, WhatsApp integration, occasion campaigns, HTML email editor, BigInt points | | [v7.19](/release-notes/v7-19) | August 2025 | Maker-checker for attributes, custom SQL reports, occasion campaigns, 30K bulk upload limit | | [v7.18](/release-notes/v7-18) | July 2025 | Referral feature, member-level capping, tier qualification methods, product code management | | [v7.17](/release-notes/v7-17) | June 2025 | Multi-provider SMS/email, on-behalf redemption, maker-checker for communications, abbreviated numbers | | [v7.16](/release-notes/v7-16) | May 2025 | Aggregate attributes in rule engine, multi-currency programs, Plum account redirection, VAPT fixes | | [v7.15](/release-notes/v7-15) | April 2025 | Peer-to-peer point transfers, decimal redemption, rule engine versioning, custom expiry dates | | [v7.14](/release-notes/v7-14) | March 2025 | PII encryption, SFTP uploads via UI, member self-service portal, rule preview | | [v7.13](/release-notes/v7-13) | October 2024 | CAPTCHA security, multi-tenant API keys, progressive login protection, Node.js 22 upgrade | | [v7.12](/release-notes/v7-12) | October 2024 | Secure LDAP, custom email branding, V4-to-V7 migration tooling, performance benchmarks | | [v7.11.0](/release-notes/v7-11) | August 2024 | Notification infrastructure scaling, user data export, member privacy control, accrual notifications | | [v7.10.0](/release-notes/v7-10) | July 2024 | Maker-checker for campaigns & tiers, CRD enhancements, rule engine export, anomaly detection toggle | | [v7.9.0](/release-notes/v7-9) | June 2024 | Communication queue optimisation, member preferred languages, point settings maker-checker | | [v7.7.0](/release-notes/v7-7) | May 2024 | Member attribute lookup API, anomaly detection improvements | | [v7.6.0](/release-notes/v7-6) | April 2024 | Maker-checker for user/role management, MSSQL report generation, projected expiry report | | [v7.5.0](/release-notes/v7-5) | March 2024 | Transaction queuing for future members, legacy auto-generated reports, communication priority handling | | [v7.4.0](/release-notes/v7-4) | February 2024 | Rule engine pre-processing, PII masking, user archive capability | | [v7.3.0](/release-notes/v7-3) | January 2024 | Member account closure, monthly e-statements, SFTP upload consolidation, audit trail | | [v7.2.0](/release-notes/v7-2) | December 2023 | Add/Modify Members API, Add Transaction API, LBMS dashboard, 157-currency support | | [v7.1.0](/release-notes/v7-1) | November 2023 | Maker-Checker module, Loyalty Points API sanity testing | # v7.1.0 — November 2023 Source: https://help-loyalife.xoxoday.com/release-notes/v7-1 Loyalife v7.1.0 introduces the Maker-Checker module for transaction approval workflows and completes sanity testing of 13 core Loyalty Points APIs. # v7.1.0 — November 2023 **Released:** November 2023 ## Maker-Checker Module ### Transaction Approval Workflow The Maker-Checker module introduces a multi-step approval flow for transactions: * Enablement requires a **manual backend entry** in the system parameters table; it is configured at the **program level** * Once enabled, the Maker-Checker workflow **cannot be disabled** **Approval flow:** 1. A user raises a transaction — it remains in **Pending** status until reviewed 2. A **Checker** verifies the transaction 3. An **Approver** approves or rejects it 4. Rejected transactions are **not credited or debited** to the member **Permission logic:** * A user with **both** Checker and Approver permissions: skips the verification step and receives Approve permission directly * A user with **Approver permission only**: must wait for a Checker to verify the transaction before they can approve it *** ## Loyalty Points API ### Sanity Testing Completed The following 13 APIs have been validated and are production-ready: | # | API | | -- | -------------------------------- | | 1 | Authentication Token | | 2 | Member Balance | | 3 | Redemption | | 4 | Reversal | | 5 | Member Transaction Summary | | 6 | Member Statement | | 7 | Points Expiry Schedule | | 8 | Member Activity | | 9 | Member Profile | | 10 | Generate OTP | | 11 | Verify OTP by Relation Reference | | 12 | Verify OTP by Email | | 13 | Member Transaction by Date | # v7.10.0 — July 2024 Source: https://help-loyalife.xoxoday.com/release-notes/v7-10 Loyalife v7.10.0 extends maker-checker to campaigns and tiers, restores point definition fields, adds CRD mandatory validations, and introduces rule engine summary export. # v7.10.0 — July 2024 **Released:** July 2024 ## Maker-Checker Expansion ### Campaigns and Tiers Maker-Checker approval is now required for campaign and tier changes: * **Campaigns:** Creation, edits, and enable/disable actions all require approval * **Tiers:** Creation, edits, and deletion all require approval * Pending action notification emails are sent on **Monday, Wednesday, and Friday** *** ## Points Definition ### Restored Configuration Fields The following fields have been restored to program configuration: * **Cashback Rate** * **Redemption Rate** * **Customer Purchase Rate** When Maker-Checker is enabled for the program, changes to these fields require approval before taking effect. *** ## Manual Points ### Redemption Reversal Reclassified * Redemption reversals are now classified as a **Credit** transaction type * An expiry date selection is available for redemption reversals * Transactions are recorded with `transaction_type = 1` and `loyalty_transaction_type = 8`, improving accuracy for reporting and program-level expiry compliance *** ## Reports ### Manual Points Auditability Columns Four new optional columns are available in all manual points reports: * **Created By**, **Created Date**, **Approved By**, **Approved Date** * These columns are blank for transactions that didn't go through maker-checker, or for BNS file, BNS API, Rule Engine, Tier, and Campaign transactions * Legacy reports (pre-v7.10.0) do not show the new columns unless the report view is recreated ### Merchant Name in Transaction Reports * A new **Merchant Name** column is available in transaction reports * Populated for **debit transactions only**; blank for all other transaction types ### Member-Level Accrual, Redemption, and Expiry Reports * Individual Accrual, Redemption, and Expiry reports can be exported directly from a member's profile * Default export window: **last 1 month**; expandable up to **1 year** * Requires View Member module and View Report module permissions * All exports are logged in the audit trail ### Credit Transfer Filter for Miles Redemption * A new **Credit Transfer** filter is available in reports for tracking miles redemption transactions *** ## Anomaly Detection * The Anomaly Detection module is now **optional** — enabled only at program level upon client request * When not enabled, the module does not appear in navigation * **Constraint:** Once enabled, anomaly detection **cannot be disabled** *** ## Liability Report * The following columns have been removed to improve performance: Points Redeemed, Net Points, Expiry Points * Optimised for datasets exceeding 100,000 records *** ## CRD File Processing ### Mandatory Field Enforcement Nine fields are now mandatory in CRD files: ActionType, StatusType, RelationReference, SubRelationIdentifier, LastSixDigits, Type, IssuedDate, ExpiryDate, ProductCode * Non-existing members cannot be added via CRD files * Invalid records are rejected and detailed error logs are available in Reports → Logs or via email notification *** ## Rule Engine ### Summary Export * Rule Engine configurations can now be exported as a summary: Attributes, Rule Groups, and Rules * Requires *"View Rules"* permission * Export is **not** logged in the Audit Trail or the Reports section *** ## Member Search * Custom member attributes (string type only) can be included in member reports with search and filter capability * This setting is toggleable at any time * CRD card numbers must be unique across programs; searching a non-unique value returns only one result *** ## Point Expiry * Batch processing for point expiry now processes in **1,000-record batches** to optimise memory and CPU usage * Expiry logic remains unchanged *** ## LDAP * LDAP authentication is verified for user creation and login * Password Set/Reset is disabled when LDAP is enabled # v7.11.0 — August 2024 Source: https://help-loyalife.xoxoday.com/release-notes/v7-11 Loyalife v7.11.0 optimises notification infrastructure for enterprise scale, adds PDF export for user management, introduces member list privacy controls, and enables rule engine accrual notifications. # v7.11.0 — August 2024 **Released:** August 2024 ## Infrastructure ### Notification Service Optimisation * The notification service has been rebuilt to handle large-scale email deliveries with high-availability (HA) mode * Infrastructure: 2 pods in HA mode + 1 on-demand pod with auto-scaling * Tested at enterprise client configuration for reliability and throughput *** ## User Management ### PDF Export for User and Role Data * User management data can now be exported as **PDF** (non-editable format) in addition to the existing CSV option * PDF files are compressed as **ZIP by default**; GZ or no compression are also available * Audit trail data continues to export in CSV format only * Access requires both User Access Management module access **and** Report module view permission *** ## Member Privacy ### "View Member List & Filters" Permission * A new **"View member list & filters"** permission restricts visibility of the member list and filter panel * Disabled by default for all roles except **Super Admin** * Users without this permission cannot view member lists or apply filters * **Exception:** The search bar and CRD card number search remain available to all users regardless of this permission *** ## Authentication ### Secure Password Reset * Password reset now uses a **secure email link** with enforced validation rules * Enables self-service password management for all users *** ## Communications ### Rule Engine Accrual Notifications * A new *"Credit by Rule Engine"* communication event sends an email notification when points are accrued successfully via the rule engine * Eligible recipients: **Active** and **Suspended** members * Members of any status (including Cancelled and Inactive) still receive points — only the notification is gated by status * Debit notifications are not yet implemented * Communication templates must be created manually — no default template is provided * Disabled templates will not send emails; multi-language template support with variable replacement is included *** ## Points Transparency ### Manual Points Details in Reports * Manual point adjustments now display full narration and transaction breakdowns in reports * Includes accrual, redemption, and expiry point specifics * Maker-Checker approval flows are fully logged; audit entries are generated for all manual points activity # v7.12 — October 2024 Source: https://help-loyalife.xoxoday.com/release-notes/v7-12 Loyalife v7.12 introduces stricter non-LDAP password security, secure LDAP, custom email branding, rule group expiry warnings, V4-to-V7 migration tooling, and a hotfix for field validation. # v7.12 — October 2024 **Released:** October 2024 ## Security ### Enhanced Password Management (Non-LDAP) * Users are limited to **one active password reset link**, which expires after 24 hours * Users cannot reuse any of their **last 4 passwords** * Passwords that contain email address components are rejected * **6 consecutive failed login attempts** trigger a 24-hour account lockout — password reset is still available during the lockout period * Secure LDAP is now supported for Azure and AWS environments; enabled via `IsLdapSecure: true` in `appsettings.json`; anonymous binding toggle is available *** ## Communications ### Program-Level Email Branding * Email branding is now configurable at the **program level**; if unconfigured, the system defaults to Giift's standard branding * Email previews display the current branding * Bulk email processing now uses a **single processing pod** instead of three, streamlining operations while maintaining reliability ### On-Demand Welcome Email API * A new API triggers welcome emails on demand, with `Program_id` and `Enrollment_date` as parameters *** ## Rule Engine ### Expiry Warnings on Rule Groups * Rule groups with **expired validity date ranges** now display a warning in the rule group listing view, the condition editor, and the rule management section * Reduces the risk of rules being triggered accidentally after their validity period ends *** ## Audit & Access * **Audit Trail** search can now be filtered by **IP address** * **Program-specific user roles:** Users can hold different permissions across multiple programs * **Program-level notification configuration:** Tailored communication events per program *** ## Performance Benchmarks | Scenario | Time | | ------------------------------------------ | ------------------ | | 1M transaction upload with product capping | 21 minutes | | Accrual notification for 1M records | 2 hours 21 minutes | | Tier progression for 7M members | 12 minutes | | Member report for 7M members with filters | 14 minutes | *** ## Migration ### V4 to V7 Migration * Roles are restructured to new role types (Program Admin, Program Manager, Customer Executive) * Pre-migration reports are archived; only liability reports are created post-migration * Database migration: \~19GB disk space, \~20 minutes for a 6M-member, 11M-transaction database * Only global member attributes migrate; local attributes require advance coordination with the Giift team * Program creation workflow condensed to **3 steps**: Program Details, User Details, Point Definitions *** ## Hotfix Enhancements ### Special Characters in Product Codes Product codes now accept: hyphens, underscores, periods, and spaces (in addition to alphanumeric characters). Applies across Points Management, Reports, Communications, and Rule Engine. ### Field Validation for Rule Creation * **String fields:** 1–150 alphanumeric characters, spaces, underscores, hyphens * **Float fields:** Up to 4 decimal places, range −999,999.9999 to 999,999.9999 * **Integer fields:** −2,147,483,648 to 2,147,483,647 * **Date fields:** Calendar widget only (no manual text entry) # v7.13 — October 2024 Source: https://help-loyalife.xoxoday.com/release-notes/v7-13 Loyalife v7.13 delivers CAPTCHA security, progressive login blocking, multi-tenant API keys, OTP encryption, non-ASCII support, and tech stack upgrades (Node.js 22, C# 8, Redis 7). # v7.13 — October 2024 **Released:** October 2024 ## Security ### CAPTCHA on Login * A **6-digit CAPTCHA** is required at login for all user types (LDAP, non-LDAP, SaaS) * Failed login attempts are limited; CAPTCHA expiration is enforced to defend against brute-force attacks ### Progressive Login Protection * After **6 failed login attempts**, the account is blocked * Blocked users can still reset their password via *"Forgot Password"* * For non-LDAP environments: a progressive error message is shown before blocking * For LDAP environments: only an error message is shown; no account block occurs * A successful login within the 6-attempt window resets the attempt counter ### Multi-Tenant API Security * Separate API keys are issued per SaaS client * Token validity is configurable (default: **30 minutes**) * Authorization is restricted to the specific client's programs ### OTP Encryption * OTPs are encrypted before storage in the database; the decrypted OTP is delivered to the member * Expired or inactive OTPs fail API verification * The OTP view option is disabled in the communication template UI for sensitive templates * Audit logs are generated for OTP resend email actions ### Password Reset Security (VAPT Fix) * The system now displays a generic confirmation: *"If the entered username exists in our system, you will receive an email with instructions to reset your password"* — regardless of whether the username exists * The API always returns true for all usernames, preventing username enumeration * Invalid CAPTCHA triggers a specific error message ### Password Encryption in Infrastructure The following passwords and keys are now encrypted via config maps: * MSSQL password * Redis password * Minio access key * SMTP password ### Sensitive Data Removed from Logs OTP and PII data has been removed from application logs across: Notifications, Milestones, Segmentation, Member, Transaction, RBAC, OAuth, and Maker-Checker modules *** ## Access Control ### Restricted Platform Configuration View * The "Organisation" view permission now shows **basic information only** * All program configuration tabs are hidden for users with this permission level ### Manual Points and Member Details Permissions * A new **"View Member Details"** permission controls access to sensitive member data * **"Add/Remove Points"** works independently — users can award points without needing View Member Details * **Auto-enable:** Granting "Add/Remove Points," "Show PI Details," or "On Behalf of Redemption" automatically enables "View Member Details" * Manual points can only be awarded to members with **Active** status ### Report Access & Sharing (RBAC) * **"Create" permission:** Full access — view, create, delete, and share reports and logs for accessible programs; share with individual or multiple users * **"View" permission:** Read-only access — view, generate, and download shared reports only; cannot create, delete, or modify *** ## Reports ### Audit Trail Export * Audit Trail reports now export as **PDF** (compressed as ZIP or GZ based on configuration) * The previous CSV export format has been removed ### Export / Import Enhancement * Roles and auto-generated reports are now exportable * On import: all existing target program roles are deleted and users are reassigned to the Program Admin role * Only auto-generated transactional, member, and communication reports are exported with their settings * No audit logs are generated for import/export operations *** ## Users ### Username Field for Business Users * Existing users' usernames are set to their email ID (applied via upgrade script) * New users are added to LDAP with their username and password * The username field is non-editable in the application * Adding the same credentials across multiple programs maps the user to all those programs * *"Forgot Password"* flows are based on the username *** ## Transactions ### Non-ASCII Character Support * Non-ASCII characters are now supported in Transaction, Member, and BNS file processing and APIs * Special characters remain prohibited in Product file uploads and the application itself *** ## Infrastructure ### Tech Stack Upgrades | Component | Before | After | | --------- | ------ | --------------------------- | | Node.js | 14–16 | 22 (LBMSUI: 20, others: 22) | | C# | 3.1 | 8 | | Redis | 5.7 | 7 | # v7.14 — March 2025 Source: https://help-loyalife.xoxoday.com/release-notes/v7-14 Loyalife v7.14 introduces PII encryption, SFTP file uploads via the UI, a member self-service hub, conditional point release, tier retention, and 20+ functional improvements. # v7.14 — March 2025 **Released:** March 2025 ## Data Security & Privacy ### Member PII Encryption Email addresses, mobile numbers, and all PI-tagged custom attributes are now encrypted at rest in the database: * Encrypted data is automatically decrypted when sent to members * Downloaded member detail files show decrypted or masked data * Custom attributes tagged as PI are excluded from reports * Deletion from storage is permanent and cannot be reversed * Available and used storage information is visible on the Loyalife UI ### PII Toggle for PI Attributes * Attributes can be marked as Personally Identifiable (PI) by admins * **UI visibility** of PI-tagged attributes is controlled by the "Show PI Details" privilege * Access to PI data is recorded in the audit trail *** ## File Processing ### SFTP File Upload via the UI Transaction and CPD files can now be uploaded directly from the Loyalife application — previously only available via SFTP: * Maximum file size: **10MB** * All validation rules from SFTP apply (file name, length, data type constraints) * Error logs are viewable in Reports → Logs * Requires *"Edit platform configuration"* permission *** ## Access Control ### Role Deletion and Permission Management * Unused roles can now be **deleted**; default roles (Program Admin, Program Manager, Customer Executive) are protected and cannot be edited or deleted * Role permissions are viewable without requiring edit access * If maker-checker is enabled, user management follows the same approval flow * Existing customers require an upgrade script to apply default role permission protection ### Dual-Mode Login (Username or Email) * Users can log in and use the "Forgot Password" flow using either their username or email address * Applies to non-LDAP, LDAP, and Cloud authentication * Generic error messages are shown for invalid username/email combinations ### Configurable Password Strength * Password length is now configurable per program * Common or easily guessable passwords are rejected * Passwords with a strength score above 3 are accepted *** ## Member Portal (Storefront) ### Self-Service Hub Members can now register, claim transactions, view history, and initiate redemption through the storefront: * Registration supports: email address, first name, last name, and mobile number (optional) * OTP verification is required upon registration * For existing members, the relation reference must match their email address * Points are displayed in whole numbers only — decimal points are not supported on the member portal *** ## Points ### Conditional Points Release Programs can configure a delay between when points are awarded and when they become redeemable: * A **Date Attribute** and **Delay Time** define when the release begins * Points are awarded per rule engine logic but remain non-redeemable until the delay has elapsed * Only transactions with confirmed status are eligible for redemption ### Post-Transaction Claims Programs can require members to explicitly claim transactions before points are credited: * Configuration sets a **Field to Validate Purchase** and a **Date Attribute** * Once a transaction is claimed by a member, it cannot be re-claimed by anyone * Unclaimed transactions remain in the queue indefinitely ### Campaigns Without Compulsory Points * Campaigns can now be configured to send communications without issuing any points * Audience targeting, delivery logs, and analytics remain fully functional *** ## Tiers ### Manual Tier Update via API * Members can be directly mapped to any tier using a batch API (maximum 1,000 members per request) * Tier bonus is issued after the next tier cron execution * Deleting a higher tier automatically downgrades affected members to the base tier at the next cron run ### Tier Custom Benefits * Non-base tiers can have up to **10 custom benefits** (welcome bonus or point multiplier) * Default values if not set: welcome bonus = 0, point multiplier = 1× * Sequencing of benefits is configurable but functionally irrelevant ### Tier Retention Policy * **Rolling Year** evaluation only — retention does not apply to upgrades * Minimum retention period: **30 days**; maximum: **365 days** * Members remain in their higher tier even if their current points fall below the tier threshold during the retention window *** ## Reporting ### Rule ID and Rule Name in Transaction Columns * Four new optional columns are available in all transactional reports: Rule ID, Rule Name, Rule Group ID, Rule Group Name * These are blank for Tier Bonus, Campaign Bonus, Expiry, and Redemption transactions * These columns do not apply to records from legacy (pre-v7.14) programs ### Claimed/Unclaimed Transaction Reporting * A *"Pending transaction"* filter is available for `transaction_type = 5` * Pending transactions are excluded from accrual and reversal reports * Unclaimed transaction reports are available to users with "Create Rule Engine" permission *** ## Segments ### Extended Filter Capabilities * The same filter can now be applied multiple times in a segment definition * Import/export functionality is supported for segments * Conflicting filters are allowed (e.g., "within 1 day" AND "not within 1 day") * Decimal values are not accepted in numeric filters — integer values only *** ## Rule Engine ### Rule Preview * Before saving a rule, users can preview the point calculation based on the last record in the transaction table * Group and product capping, and anomaly detection are **excluded** from the preview * If no transactions exist, a new transaction can be added for preview purposes * Includes transaction type 5 (pending state) *** ## UI Improvements * **Program Logo:** Images are auto-adjusted for dimensions; images larger than 500×500 require manual crop/zoom * **Pending Transactions on Storefront:** Visible with a *"Credit Pending"* tag regardless of whether the value is positive or negative * **Country Code Rendering:** Configurable per client; France is pre-configured as default for the self-signup registration flow * **Multi-Language Storefront:** Language selection via Weglot configuration; French and English tested; text briefly displays in English before switching # v7.15 — April 2025 Source: https://help-loyalife.xoxoday.com/release-notes/v7-15 Loyalife v7.15 introduces peer-to-peer point transfers, decimal redemption, rule engine versioning, custom bonus expiry, and GraphQL performance improvements. # v7.15 — April 2025 **Released:** April 2025 ## Performance * GraphQL API performance enhanced with improved TPS (transactions per second) and response times * Duplicate tier tables removed from the database, reducing load; tier data consolidated into the primary tier configuration and mapping structures *** ## Members ### Peer-to-Peer Point Transfers Members can now transfer points to other members within the same program: * Cross-program transfers are not supported * Eligible statuses: all except Cancelled and Closed * Transfers appear in Reports with the *"Peer-to-Peer Transfers"* filter ### Decimal Point Redemption * Redemption API now accepts up to **5 decimal places** * Values beyond 5 decimal places are truncated * Rounding is applied to the nearest whole number; excess is recorded as spoilage in reports * Reversal returns the full amount including spoilage ### Auto-Claim for Future Transactions * Once a member manually claims a transaction for the first time, **all subsequent transactions are auto-claimed**, regardless of transaction type (CR/DR) * Works across all claim states: claimed, pending, ready to redeem ### Profile Editing * Members can edit their **first name**, **last name**, and **mobile number** * Mobile number uniqueness is enforced across the program * Changes are reflected in the admin panel after update *** ## Rule Engine ### Rule Versioning with Full Audit Trail * All rule edits are version-controlled — each edit creates a new version and the latest version is used for computation * Users can view the full edit history and download a version summary * Archived rules must be unarchived before they can be edited * Maker-Checker applies to rule edits if enabled for the program * "Created by" displays as "NA" for rules imported from another program ### Transaction Template Events * Communication events now support both **pending** and **completed** transaction states * Pending mail trigger: runs every 2 minutes; the pending status must persist for at least 2 minutes before a pending notification is sent * If the transaction completes within the 2-minute window, only the completed mail is sent * Status eligibility for receiving templates: Active, Suspended, Blocked receive mail; Cancelled, Closed, and Inactive do not *** ## Access Control ### Role Permission Improvements * A new non-selectable **"Create Program"** permission has been introduced * Role permission counts now include this permission in the total after role creation * Import/export role access counts reflect the exported program's state *** ## Points & Expiry ### Custom Expiry Dates for Bonus Points Custom expiry dates can now be passed when awarding bonus points: * Applicable across: Bonus API, BNS file, Manual Points, and Campaigns * The custom expiry date **overrides** the program-level expiry configuration * **Validation rules:** * Bonus requests: expiry date must be ≥ current date * Campaign context: expiry date must be > campaign end date * Custom expiry can exceed the program's standard expiry date * Negative point entries: expiry is not applied * Campaign limitation: custom expiry applies to reward-type campaigns only, not promotional campaigns *** ## User Management ### Enhanced Username Autofill * When an email already exists in the system, the username auto-populates and the field becomes locked * For new emails, the username is entered manually * A user whose email is already mapped to a username in another program cannot be re-added with a different username * Archived or locked users can be re-added; archived users are moved to the home page, locked accounts are unlocked automatically *** ## Claim Messaging * Error and success messages for the claim transaction flow are now specific to each scenario: missing parameters, invalid values, duplicate claims, pending state, confirmed state, and successful claim # v7.16 — May 2025 Source: https://help-loyalife.xoxoday.com/release-notes/v7-16 Loyalife v7.16 introduces aggregate attributes in the rule engine, configurable points expiry, Plum marketplace redirection, multi-currency program linking, and 15 VAPT security fixes. # v7.16 — May 2025 **Released:** May 2025 ## Rule Engine ### Aggregate Attributes for Volume-Based Logic Programs can now create aggregate attributes that compute running totals for use in rule conditions: * **Eligible base types:** Float and Integer (global and local attributes) * **Aggregate functions:** Sum, Min, Max, Average, Count * **Time periods:** Lifetime, MTD, QTD, YTD, Rolling (last 365 days) * Optional conditional logic can be applied during attribute setup * Once created, only the **name** can be edited; deletion is only allowed when the attribute is not used in the Rule Engine * Aggregation is computed from incoming data (file or API) — historical data is not re-computed **Time period notes:** * *Rolling Year:* Covers the last 365 days; members outside this window remain in summaries but do not receive points * *MTD/QTD/YTD:* Computation occurs even without a current-period transaction; data is stored per transaction date **Performance benchmarks:** * 1M transactions + 10 aggregate attributes ≈ 4.7M records processed in 8–10 minutes * Full points issuance run with capping ≈ 220 minutes total *** ## Points Configuration ### Revamped Points Definition Setup The Points Definition screen is reorganised into three unified sections: * **Point Terminology & Rates:** Points terminology, Cashback Rate, Customer Purchase Rate, Redemption Rate * **Expiration Details:** Expiration schedule, period, and start condition * **Claim & Pending Points Management:** Moved under Points Definition; toggles are non-editable if required global attributes are missing The standalone "Attribute Setting" option previously in Rule Engine Attribute Setup has been removed. ### Configurable Points Expiry Trigger Points expiry can now be triggered from either the **Processing Date** or the **Availability Date**: * Default is Processing Date; the option to change it is only available once Claim & Pending Points Management is configured * Expiry begins when the transaction status changes to confirmed (status = 1) * When anomaly detection is enabled, expiry is calculated **after** the transaction is approved ### Monthly Email Statement Toggle * A new enable/disable toggle is available in Communication Settings (enabled by default) * Requires "Create communication template" permission * Once a member receives a monthly statement, they will not receive another for the same month even if re-triggered * Compatible with both new and existing programs ### Monthly Cap Limits Removed * Product Code monthly cap validation has been removed; values exceeding 100,000 are now accepted * Rule Group limits now accept values beyond 5 digits without validation errors *** ## Marketplace ### Plum Account Redirection from Loyalife Admins can configure storefront Plum redirection under Platform Settings: * Requires platform view and edit configuration permissions * **Role-based redirection:** Super Admin → Plum admin portal; Admin → Plum marketplace/end-user section; Unregistered → member view with no admin switch * Password resets must be performed from the **Loyalife portal** — not from Plum * Credential validation is not performed in real-time during setup; errors appear in the UI during login * Token mechanism: refresh tokens generate access tokens; if the refresh token expires, the user is not redirected to Plum *** ## Multi-Currency ### Linked Program Management Program Admins can link two independent programs for multi-currency operations: * This is a **one-time, irreversible** action — programs cannot be delinked once joined * Module-level switching is supported (e.g., Member module) * Detailed actions and views are limited to linked modules only * Proper error messaging is displayed when a member exists in one program but not the other *** ## Members ### CRD LastSixDigits Uniqueness Removed * Zero values are now accepted for LastSixDigits and SubRelationIdentifier * Either `CardNumber` or `SubRelationIdentifier` must be non-null and non-zero — providing both as null/zero is rejected with: *"CardNumber and SubRelationIdentifier both cannot be empty together"* * After insertion, `CardNumber` and `SubRelationIdentifier` are immutable * The Get API returns all members matching a given `CardNumber` or `SubRelationIdentifier` ### Enhanced Member Transaction API * `GetMemberTransactionSummary` and `GetMemberTransactionSummaryByDate` now return local transaction attributes * Compatible with both legacy and new programs *** ## Reports ### Purchase Eraser Report * A new *"Purchase erases"* filter is available in transaction reports * Not included in default system reports; admins must create a custom view * Classification criteria: `loyalty_txn_type=47` AND `transaction_type=2`; transaction narration: *"Redemption DebitTransfer"* ### Report Generation Improvements * Preview capability lets users verify the report setup before generating * Manual reports can be generated from an auto-report configuration; naming convention: `[Parent Report Name]_[StartDate-EndDate]` *** ## User Experience ### Sidebar Redesign * Each sidebar module now has a unique icon with an accurate tooltip * "Organisation" removed from the top navigation * "Manage Users" and "Manage Roles" are consolidated into a single **Manage Roles** section ### Improved User Creation Flow * Email ID appears before username in the creation form * If the email already exists in the system, the username auto-populates and the field is locked * New email addresses require manual username entry with basic validation *** ## Branding * Sender email updated to `no-reply@xoxoday.com`; default sender name updated to **Loyalife** * All LBMS/Giift references have been removed from email templates * Existing program configurations are not affected *** ## Security * All VAPT vulnerabilities flagged by the Seciq external penetration testing team for 2025 have been resolved and verified; a security certificate has been issued # v7.17 — June 2025 Source: https://help-loyalife.xoxoday.com/release-notes/v7-17 Loyalife v7.17 adds multi-provider email/SMS, LDAP nested OU support, on-behalf redemption, maker-checker for communications and suspension, recurring date rules, and abbreviated number display. # v7.17 — June 2025 **Released:** June 2025 ## Communications ### Multi-Provider Email & SMS Configuration Programs can now override the default email and SMS provider at the program level: * Configuration is managed by DevOps — it is not exposed in the standard UI * Program-level settings override the deployment default * If a program-level setting is misconfigured, email and SMS for that program will fail — the system **does not fall back** to the default configuration ### Maker-Checker for Communication Templates Promotional, transactional, and custom event templates now require approval before activation: * The existing campaign maker-checker permissions are extended to the Communication module * Pending notification emails include both campaign and communication approval requests *** ## Authentication ### LDAP Nested Organisational Unit Support * Users from different Organisational Units (OUs) can now log in, create programs, and perform all activities * Nested OU structures are supported — LDAP users in nested OUs gain full access * The same user cannot exist in multiple OUs simultaneously * Password reset and change password features remain disabled when LDAP is enabled * LDAP users can access the marketplace as members *** ## Members ### Maker-Checker for Member Suspension A new approval workflow governs suspend and reactivate actions: * Two new permissions: **Verify Suspension Action** and **Approve Suspension Action** * Configured under Program Settings → Modules → Suspension Actions * Scope: suspend and reactivate only — does not apply to blocked members * **Blocked member exception:** Reactivation of blocked members is immediate (no maker-checker required) * Audit trail records checker/approver actions with timestamp and user identifiers * Pending notification emails include suspension action requests ### Member Suspension Workflow (RBAC Lock/Unlock) * Lock/Unlock and Archive/Unarchive actions for business users are also governed by the Suspension Actions module * Audit trail captures approve/reject actions; pending notification emails include these requests *** ## Points & Expiry ### Updated Bulk Expiry API * The `ProcessExpiredPoints` API has been deprecated and replaced by `ProcessBulkExpiredPoints` * Quarterly expiry can now be triggered in **any month** within the expiry window — previously it required triggering at the start of the quarter ### OTP Length Configuration * OTP length is now configurable via the `OTPLength` config variable (valid range: 4–8 characters) * Defaults to **4 characters** if the configured value is outside the valid range * Affects `GenerateOTP` and `GenerateOTPByRelationReference` APIs (Login and Activation OTP types) * OTPs are encrypted in the database and decrypted before sending *** ## Reporting ### Automated Monthly Transaction Report * Monthly and quarterly transaction reports are auto-generated for programs on a scheduled cron * Handles up to **1 million members** in approximately 10 minutes * Configurable API parameters: Program ID and recipient email address ### Transaction History Date Filters * Date range filters added to member transaction history with pagination and a rows-per-page selector * Initial display shows the last 5 transactions; users can search by processing date * **Pending transactions** (transaction\_type = 5) are now visible in the member transaction summary on the admin portal * SFTP log improvements: row count tooltip on hover for successful logs; download option available for all statuses (Successful, Failure, Incomplete) *** ## Redemption ### On-Behalf Redemption Authorised admin users can now redeem on behalf of members: * Requires *"edit platform configuration"* permission to configure the storefront URL * Three member permissions required: **View Member Details**, **View Member**, and **On Behalf of Redemption** * Member must have Active status * Audit log is created when the admin accesses the member's account on behalf * A confirmation email is sent to the member upon redemption * Transaction narration: *"Redemption GiftCard"* * Reports include a new *"On Behalf User"* column showing the username of the admin who performed the redemption * *"On behalf redemption"* filter shows only on-behalf activity; *"Debit by redemption"* includes both standard and on-behalf transactions *** ## Segments * Segment names must now be **unique** (case-insensitive); attempting to create a duplicate name returns an error * The **Tag** field has been removed from segment creation and all selection interfaces * Existing segments continue to function without changes *** ## Rule Engine ### Recurring Date Attributes Three new attribute types for time-based rules: * **Day of Week** * **Month of Year** * **Day of Month** These can be used in rule conditions and are compatible with existing date logic and reward calculations. They apply to rules only — not to rule groups. *** ## Programme Settings ### Abbreviated Number Formatting * A new **"Enable Abbreviated Numbers"** toggle is available under Program Settings → Points Definition → Point Terminology & Rates * When enabled: points are displayed as K (thousands), M (millions), B (billions) on the storefront * When disabled: points display in standard numeric format *** ## Naming Flexibility * Programs, products, and rules can now share names — internal IDs remain unique * Duplicate segment names are still rejected; all other entity names now allow duplicates *** ## PII in Reports * A new **Advance Config setting** (admin-only, program-level) allows email and phone number to be included in member reports * This setting is a **one-time enablement** and cannot be reversed * Only users with report creation permission can export reports that include PII data # v7.18 — July 2025 Source: https://help-loyalife.xoxoday.com/release-notes/v7-18 Loyalife v7.18 introduces the Referral feature, member-level point capping, program-level tier qualification methods, product code management, manual segment uploads, and a storefront tier widget. # v7.18 — July 2025 **Released:** July 2025 ## Referrals ### Referral Program Setup A new **Referral** section enables programs to track referrals, generate unique codes, and reward members for successful referrals: * Two new role privileges: **Edit Referral Setup** (create and modify configurations) and **View Referral Setup** (view-only access) * Edit and View referral permissions are enabled by default for Program Admins in existing programs * Enabling the referral program is a **one-time action** — it cannot be disabled once activated * The system auto-creates two custom attributes: **Referral Code** and **Referred By** — both are String type and cannot be edited ### Referral Code Rules * Custom referral codes can be passed via CPD files or APIs * Once a referral code is assigned to a member, it **cannot be edited or updated** * The same referral code cannot be assigned to two different members * Empty values passed via API or CPD will not update an existing referral code * Passing an existing member's referral code for a different member is rejected ### Reward Triggers Referral rewards are configurable with two trigger options: * **On Activation** — reward issued when the referred member activates * **On First Transaction** — reward issued when the referred member completes their first qualifying transaction *** ## Tiers ### Program-Level Tier Qualification Method A new **Tier Qualification Method** section is available in Tier Settings (requires tier creation permission): * **Points:** Member movement is based on point thresholds * **Aggregate Attribute:** Member movement is based on configured aggregate attribute values * **Both:** Movement occurs when either the points or the aggregate attribute condition is met * Changing the qualification method triggers **automatic member re-evaluation** and tier movement * For automatic tier mode, members can see current tier, next level, and progression details; for manual tier mode, only the current tier is shown **Backward compatibility:** * Tiers previously configured with Points Only display as "Both" with actual points and zero aggregate value * Deleting a higher tier automatically downgrades members to the previous tier based on the configured method *** ## Member-Level Capping ### Capping Across All Loyalife Sources Member-level capping now applies across all point sources simultaneously: * **Sources covered:** Rule Engine, Manual Points, Tier Bonus, Campaign Bonus, Referral Bonus * A member at the capping limit becomes ineligible for points from all sources for the remainder of the month * Cap limit changes made after the month starts take effect in the **following month** **Three capping levels (all enforced):** * Rule Group Capping * Product Code Capping * Member-level Capping **Partial accrual support:** * If a member has 450 points accrued against a 500-point cap, the next transaction awards only 50 points **Negative transactions free up cap space:** * Example: 1,000-point cap, 900 points accrued, −500 debit → 400 points used, 600 available again **Anomaly detection sequencing:** * Capping logic runs first (Rule Group → Product Code → Member level) * Points consumed by capping are deducted from the member's capping limits immediately * If anomaly detection subsequently rejects the transaction, the capping deduction is **not reversed** *** ## Members ### Member Attribute Editing Attributes can now be edited, subject to conditions: * Editing is only permitted when the attribute is **not used** in Segments, Reports, or Communication modules, and contains no existing member data * All edits are logged in the audit trail **Permitted constraint changes:** mandatory → non-mandatory; unique → non-unique; non-unique → unique **Not permitted:** non-mandatory → mandatory *** ## Segments ### Manual Segment Uploads A new **Manual Segment** feature allows programs to define custom member groups via CSV upload: * **Append mode:** Adds new members to the existing segment; shows counts for existing and newly added members * **Replace mode:** Replaces all existing segment members with the upload; shows removed and newly added member counts * Supports all member statuses: Active, Inactive, Suspended, Cancelled, Blocked * Email notifications are sent for successful, failed, and partial success outcomes * Deletion is blocked when the segment is used in an active campaign * Non-existing members in the CSV are skipped; existing members are inserted successfully **Performance benchmarks:** * 5K members: \~3 minutes * 20K members: \~13 minutes * 100K members: \~1 hour 18 minutes *** ## Rule Engine ### Attribute Value Grouping Groups of values can be created for local attributes of type Integer, String, or Selection: * Creation methods: CSV file upload or manual entry * Groups are **non-editable and non-deletable** after creation * Duplicate values are allowed across different groups; duplicates within the same group are rejected * Special characters and empty values are accepted; only valid values appear in the UI * The *"In Group / Not In Group"* operator is visible during rule creation but cannot currently be saved with this operator (known limitation) *** ## Product Codes ### Product Code Management * Search product codes by name or identifier * Enable or disable product codes across all modules * Disabled codes are rejected in transactions, CRD files, and API calls * Disabled codes **are accepted** in Bulk Points Uploads and BNS operations * Product name editing is only available via the edit link — not through bulk upload * Duplicate product names are allowed; product codes must remain unique * Enable/disable actions are not logged in the audit trail **Validation timing note:** If a product code is enabled when a manual points or rule engine request is created and then disabled while the request sits in maker-checker or anomaly detection, the request can still be approved and points will be awarded *** ## Reports ### Accrual, Redemption & Bonus Reports to Azure Storage Active auto-generated reports are automatically transferred to Azure blob storage on a daily schedule: * Manually generated and exported reports are excluded * Only active-status reports are eligible; deleted or transitional files are not transferred * Transfer is filtered by date range and program ID * A 1GB file (compressed to \~15MB) transfers within 1 minute *** ## CRD & Card Data ### CRD Status Display and Card Export Controls * A program-level setting **"Enable accounts and card linking to Members"** controls card export visibility * Requires **View PI** or **Create Report** permission to initiate a new export * Viewing card details requires **Show PI**, **View Member**, and **View Member Details** permissions — plus the program-level setting being enabled * All card data access is logged in the audit trail for compliance *** ## Storefront ### Tier Widget A new widget on the member storefront shows tier progression details: * Displays current tier, next upgrade level, and the exact amount needed to reach the next tier * Hidden until the tier cron job has run at least once (the cron assigns the member to the base tier) * For **Automatic Tier** mode: full progression details shown * For **Manual Tier** mode: only the current tier is shown; next upgrade details are hidden *** ## Localisation * All user-facing text updated to **American English** conventions (e.g., "organisation" → "organization") across Member, Segment, Rule Engine, Communication, and Reports modules * Manual points error message updated to reflect the new maximum of **20 million points (20M)** # v7.19 — August 2025 Source: https://help-loyalife.xoxoday.com/release-notes/v7-19 Loyalife v7.19 delivers maker-checker for member and rule engine attributes, Membership Blocked status, custom SQL reports, pre-processing for SFTP files, and 35 total features. # v7.19 — August 2025 **Released:** August 2025 ## Compliance & Audit ### Audit Trail for Bulk Points Adjustments All bulk points adjustment file uploads and approval/rejection actions are now captured in the audit trail: * Recorded fields: Date (YYYY-MM-DD HH:MM:SS), Username, Action category (*"Bulk points adjustment"*), Page URL, Activity description (includes filename), IP Address, Browser info ### Maker-Checker for Member & Rule Engine Attributes A new **Attribute Management** approval workflow is available under Advanced Configuration → Modules: * Once activated at program level, **it cannot be disabled** * All of the following are routed through the approval workflow: create, edit, and delete operations for member and rule engine attributes; enabling/disabling product codes; adding, editing, and bulk uploading product codes; sub-product code operations; and aggregate attribute modifications * A CSV export for approval tracking is available from both the Pending view and the All Actions view * Only users with Maker, Checker, or Approver roles can see this export * Exports are available under Reports → Administrative Data ### Maker-Checker Tracking Report * CSV export available for Pending and All Actions views from the approval workflow * Access restricted to users with Maker/Checker/Approver roles * Each export action generates an audit trail entry *** ## Member Management ### Membership Blocked Status A new **Membership Blocked** status enables complete program restriction: * **Login Blocked** (renamed from "Blocked"): restricts login and redemption; accrual is still allowed * **Membership Blocked** (new): restricts login, all forms of accrual (transactions, referrals, campaigns, peer-to-peer, API, bulk uploads, SFTP), and redemption * Requires the "Allow Membership Block" permission; Maker-Checker approval required with a reason * All actions are logged in the audit trail with user, timestamp, and reason ### Dynamic Column Configuration in Transaction Summary * Users can customise which columns appear in the Member Transaction Summary * **Default columns (always visible):** Merchant Name, Amount, Points, Transaction Date, Processing Date, Transaction Type, Narration * **Narration is visible by default and cannot be deselected** * Additional selectable columns: Global Attributes, Local Attributes, System Attributes * Column selections are session-based; they do not persist after logout or program change *** ## Reports ### Custom SQL Reports SQL-based custom reports are now configurable: * Accepts SELECT and EXEC statements only; other SQL keywords are restricted * Variables are automatically replaced during report generation * Supported generation schedules: Daily, Weekly, Monthly, Yearly, Custom Monthly Range, One-time * Only administrators can create custom reports; users with "Create Report" permission can view, delete, and share; users with "View Report" permission can only view shared reports * Variable changes take effect from the next cron execution onwards ### Automated Report Upload to Azure Blob Storage Active auto-generated reports can be automatically transferred to Azure blob storage: * Only **active-status** reports are eligible for transfer; deleted reports are blocked * Transfer can be configured with optional Maker-Checker approval before upload * Requires the "Manage Report Automation" permission * Deleting an automation configuration disables future uploads but retains history ### Report Configuration & Download Overhaul * **Unified Report Columns selector:** Global Columns and Custom Columns are merged into a single "Report Columns" picker * **Unified Report Filters section:** Filters and Narration are consolidated * Flexible period generation: Daily, Weekly, Monthly, Quarterly, Yearly, Custom Monthly Range (up to 5 date ranges) * Download most recently generated report directly from the listing screen * The View section displays all generated reports with pagination, including file name, date of generation, period, status, and download options *** ## Rule Engine ### Time-Bound Rule Groups with Points Holding Rule Groups with defined timeframes can now hold points pending maker-checker approval: * **Lifetime Rule Groups:** Always active; points are credited immediately * **Time-Bound Rule Groups:** Points are held in a staging area until the rule group period ends * An Approval Workflow toggle is available per time-sensitive rule — once enabled, it is irreversible * A CSV is auto-generated per rule with member details and points held * **Checker approves:** Hold records move to the accrual bucket * **Checker rejects:** Rejection file is available for download; rejected members can be re-uploaded via Bonus File Upload * Anomaly detection is skipped for time-bound transactions under approval ### Segment Linkage with Rule Groups * Only Manual Segments can be linked to Rule Groups (Smart/Dynamic Segments are excluded in this version) * Default: "All Members" when no segment is selected * Linked segments cannot be changed after the Rule Group is created * Segments linked to Rule Groups or Campaigns cannot be deleted *** ## Data Processing ### Pre-Processing Functions for SFTP Files Super administrators can configure pre-processing transformations on CPD and TXN files before they enter the main processing pipeline: * **Scope:** CPD and TXN files only — BNS, CRD files and API data are excluded * **Supported formats:** .csv and .txt with comma-separated or pipeline delimiters * **Test function:** Limited to 100 records **Available operations:** *Column management:* Create or remove columns using dynamic attributes, static values, or combinations; supports operators: equals, not\_equals, greater\_than, less\_than *Row management:* Remove rows via multiple if-else conditions; add rows by duplicating previous row data; skip specific cell values *Cell updates:* Modify specific cells using conditional if-else logic; respects data type constraints *Delimiter conversion:* Convert pipeline-delimited files to comma-separated; supports headerless files via index matching *** ## Marketplace & Redemption ### Storefront Country-Based Redirection * Members who register or update their profile country are automatically redirected to the appropriate storefront * India or non-UK/US/Canada members are directed to the global storefront; UK, US, and Canadian members are directed to a regional storefront ### Discount Voucher Support * Storefront redemption now tracks discount voucher scenarios where a member pays fewer points than the bank's cost (the bank absorbs the discount) * New optional API fields: `original_amount`, `original_points_before_discount`, `discount_code`, `discount_value`, `discount_type` (FIXED or PERCENTAGE only) * Backward compatible — storefronts not passing these fields continue to function unchanged ### Discount Coupon Codes at Checkout * Discount coupon codes can be applied at checkout for E-Vouchers, Shop, and Mobile Top-up categories * Codes are generated and managed by the client team * After purchase, coupon usage is visible in Order History and delivery emails; admin can view via Transaction Reports *** ## Points ### BigInt Support for Transaction Points * Point values in the Rule Engine now support up to **16-digit values** via BigInt * UI display limits for other modules remain unchanged ### GL+1 Report: Original Points Before Discount * The GL+1 report now captures `original_points_before_discount` alongside net redeemed points * Formula updated: `AMOUNTLCY = original_points_before_discount × Redemption rate × 100` * Backward compatible — if the field is empty or not provided, the system uses the existing redeemed points value # v7.2.0 — December 2023 Source: https://help-loyalife.xoxoday.com/release-notes/v7-2 Loyalife v7.2.0 introduces the Add/Modify Members API, Add Transaction API, an LBMS dashboard, custom member attributes, 157-currency support, and data export capabilities. # v7.2.0 — December 2023 **Released:** December 2023 ## APIs ### Add / Modify Members API Members can now be created and updated via API, eliminating the requirement for CSV-only bulk upload: * **Performance:** 134 TPS (single pod, 50 concurrent users, 5-minute load test, 365ms average response time) * Validations implemented: data type mismatches, unique constraints, mandatory constraints * **Pending (future releases):** Attribute-level validation with specific error codes; audit logging for API-added members; UI metrics for processed/rejected record counts ### Add Transaction API Transactions can now be submitted via API in addition to CSV file upload: * **Performance:** 70 TPS (single pod, 50 concurrent users, 5-minute load test) * Batch processing is triggered via a *"computation start"* job API; minimum interval between batches: **5 minutes** * Minimum interval for the subsequent points update job: **2 minutes** * Validations: data type mismatches, unique constraints, mandatory constraints * **Pending:** Attribute-level validation; UI display of processed/rejected metrics ### Credit/Debit Transaction Configuration * `transaction_type` in the attribute parameters determines point direction: * `"DR"` → credit points * `"CR"` → debit points * Invalid values prevent the record from being processed during computation *** ## Dashboard ### LBMS Overview Dashboard A new dashboard provides real-time and historical metrics across three categories: **Monthly**, **Yearly**, and **Current State**: * Data is cached in Redis and refreshed every **5 hours** from the database (configurable) * A cron job runs **once daily** (typically midnight) to compute and populate the cache *** ## Member Attributes ### Custom Attribute Creation Admins can now define custom member attributes beyond the standard set: * Configurable data types and constraints (mandatory/unique) * Members can be uploaded with **Active** status directly (previously all new members defaulted to Inactive) * **Validation limitation:** No regex or format checks (email, mobile, gender) — only type-based validation (string vs. int, unique/duplicate detection) *** ## Data Export * Export capabilities are now available for **members**, **transactions**, and **communication data** * Deletion is governed by the program's report retention settings *** ## Currency Support * Program creation now supports **157 currencies** *** ## Audit Logging * The audit log UI now includes a **Status** field and a **File Name** field for upload tracking * A new **Member Activity** section displays marketplace activity; testable via the InsertMemberActivity API # v7.20 — November 2025 Source: https://help-loyalife.xoxoday.com/release-notes/v7-20 Loyalife v7.20 ships Email OTP 2FA, WhatsApp integration, occasion reward campaigns, HTML email editor, member-level capping, 41 total features including BigInt points and block code mapping. # v7.20 — November 2025 **Released:** November 2025 ## Authentication & Security ### Two-Factor Authentication — Email OTP A second authentication layer is added to the login flow: * After 6 invalid OTP attempts: account locked for 24 hours (*"Too many invalid OTP attempts. Try again after 24 hours"*) * After 6 OTP resend clicks: locked for 30 minutes (*"OTP limit reached. Please try again after 30 minutes"*) * A user locked in one program can still log in to other programs via 2FA * A user locked in **all** programs cannot log in, but still receives the OTP * Username and email are masked on the 2FA screen for privacy * OTP expiration timer and resend limit are both visible to the user ### Inactivity-Triggered Password Reset * Users are redirected to a forced password change screen after N days of inactivity (default: 30 days) * The inactivity threshold is configurable per client * Users access the dashboard immediately after changing their password ### PII Encryption Toggle (Irreversible) * The PII encryption toggle is now **one-way** — once enabled, it cannot be disabled * PI attribute visibility throughout the platform is controlled by the toggle state ### CAPTCHA Configuration * A `HideCaptcha` flag controls whether CAPTCHA appears on the login page * When the flag is `true`, CAPTCHA is skipped; otherwise, the existing CAPTCHA flow applies ### LDAP: Password Reset Hidden * When LDAP authentication is enabled, the **Change Password** and **Reset Password** options are hidden across all areas: Manage Team, Profile, Login screen, and Dashboard *** ## Member Management ### Membership Blocked Status A new **Membership Blocked** status provides complete program restriction: * Login restricted * Point accrual restricted (transactions, referrals, campaigns, peer-to-peer, API, bulk uploads, SFTP) * Redemption restricted * Differs from the existing **Login Blocked** status, which restricts login and redemption but still allows accrual ### Member Fetch via Any Attribute * The frontend (storefront or admin panel) can now retrieve member details using any member attribute — custom or global * Enables a consolidated view of all accounts under a single CIF (same person, multiple cards) ### Available Offers API * A new API returns active Rule Groups filtered to only those where the member belongs to an associated segment * Rule Groups without active rules are excluded * Rule Groups whose date range is outside the validity window are excluded, even if they contain active rules ### Auto-Activate New Members on Upload * Setting `AUTO_ACTIVATE_NEW_MEMBERS: true` in the program configuration automatically activates new members during CPD file uploads * Member status in the file must be **N** (New) * This setting applies to file uploads only — not to API-based member creation *** ## Campaigns & Engage ### Occasion Reward Campaigns A new **Occasion Reward** campaign type is available alongside existing campaign types: * **Supported occasions:** Birthday and Program Anniversary * **Anniversary sub-types:** Activation Date or Enrolment Date * Target audience selection is not required — eligibility is determined automatically based on milestone dates * **Only editable after creation:** Campaign name and bonus points * Members with **Membership Blocked** status do not receive points * Occasion reward points appear under the *"credit by bonus"* filter in transaction reports * One birthday bonus and one anniversary bonus are issued per member per calendar year * Failed deliveries are logged and automatically retried ### WhatsApp Integration (Twilio / Infobip) WhatsApp is now a supported communication channel: * Supports both transactional and promotional **text-only** templates (Phase 1) * Submission status is **Pending for Approval** until Meta approves the template via Twilio Content API * Approved templates are displayed in the UI; approved templates cannot be edited * Templates with unapproved WhatsApp variants are blocked from campaign selection * WhatsApp appears as a filter in Communication Reports alongside Email and SMS * **Note:** Delivery status tracking and retry handling require a full developer account to test *** ## Rule Engine ### Voucher Issuance as a Reward Action Rule Groups can now issue vouchers instead of points: * Two reward action types at Rule Group level: **Points** and **Voucher** * Reward action type is selected at the Rule Group level and **cannot be modified later** * Voucher availability requires a configured Marketplace (Plum) integration * Country, voucher category, and voucher name are fetched dynamically from the Marketplace API during rule creation * If a member has an empty email address, no voucher is issued; only 0-point accrual is recorded * If a voucher becomes inactive after the rule is set up, the transaction proceeds but no voucher is issued * Voucher reward groups cannot be exported in the module export * **Plum Marketplace API supports Gift Cards only** ### Description Stamping Control * A new checkbox on each rule controls whether the rule name is stamped as the transaction description * When enabled, the rule name always overrides the transaction description * When disabled, the transaction description is blank * Can be toggled on or off via the edit rule option * **Applies only to rules with Reward Action = Points** — not to Voucher reward types ### Rule Engine Attribute Setup Revision * Creating a new Rule Engine redirects the user to the mandatory attribute setup page first * During initial setup, the following are disabled: product code edit, search, enable/disable * Attribute groups cannot be created during initial setup ### Zero-Point Transaction Elimination * When a transaction passes through a Rule Group but no rules are applicable, **no transaction record is created** * If a rule matches and the result is 0 points, a transaction record is still created * If a rule matches and the result is >0 points, a normal transaction is created ### Rule Group Description Field * A description field is now available during Rule Group creation and updates * Descriptions are saved, displayed, and remain editable at any time ### First Transaction Qualification Fix * The "first transaction" definition now applies a filter for `loyalty_transaction_type = 1` * Only rule engine or manual point allocations are considered — bonus, tier, and campaign points are excluded *** ## HTML Email Editor ### GrapeJS Drag-and-Drop Editor A full HTML email editor is now available in the Email Template section: * Drag-and-drop components: text, image, link, button * Pre-built branded blocks: header, body, footer * Multilingual support enabled * Dynamic placeholders (e.g., `member_name`, `points_balance`) are replaced in real-time * Preview and test-send capabilities available * HTML upload is available via the Add HTML section * Existing templates are migrated to GrapeJS (some alignment adjustments may be needed) * Variables are available in the Available Variables section and must be copied manually *** ## Points & Transactions ### Session-Based Column Configuration * Users can select which attributes are visible in the Accrual section * Selections persist until logout or program change (session-based, per user persona) * A **Reset to Default** option is available ### Automated 3-Year Transaction Housekeeping Transactions older than 3 years are automatically deleted via a scheduled cron job: * **Eligible for deletion:** Standard accrual (`transaction_type = 1`) and debit (`transaction_type = 2`) records only * **Excluded:** Pending transactions (`transaction_type = 5`) * After deletion, summary records are created and displayed as: *"Accrual Housekeeping"*, *"Expiry Housekeeping"*, *"Redemption Housekeeping"* * A **Monthly Housekeeping Summary Report** is generated after each run, showing the transaction classification, cumulative points deleted, execution date, and the user (System) ### Manual Bonus Upload Limit Increase * Maximum file size increased from **1,000 records** to **30,000 records** per upload ### Debit/Credit Card Block Code Mapping Cards are mapped to colour-coded block categories that determine member access: * **Green** (full access): Members can accrue rule engine points, access D-Point, and points expire normally * **Yellow / Orange** (partial debit restriction): Varying accrual and D-Point access depending on the specific code * **Pink** (partial restriction): Members can accrue points for some codes; cannot access D-Point; points do not expire; member status is unchanged * **Red** (full restriction): No rule engine accrual; no D-Point access; points expire; member status set to Cancelled **Mixed card scenarios:** * Green card + any pink/red card: D-Point access retained with the active card; points do not expire; status unchanged * Green → Pink transition: D-Point access removed; points do not expire; status unchanged * Green → Red transition: D-Point access removed; points expire; status becomes Cancelled ### BigInt for Custom Number Attributes * Transaction and member custom attributes with number/integer data types are now stored as **BigInt**, supporting up to 16-digit values * Applies only to newly created attributes ### Card/Account Number Uniqueness Removed * The uniqueness constraint on the last six digits and sub-relation identifier has been removed * CRD insertion is still rejected if both fields are null or empty *** ## Reporting ### Custom Report Headers Standardised headers added to: Monthly Housekeeping Summary, Monthly Customer Tiering, Customer Outstanding, Monthly/Daily Custom Reports (Transaction Type/Points/Amount), Monthly Cancelled Points, and Monthly GL+1 Approval Summary ### Transaction API Rule Metadata The member transaction summary API now exposes: `rule_group_id`, `rule_group_name`, `rule_name`, and `rule_id` in both API responses and reports ### Custom Reports for BDI Six specialised reports added for BDI clients: * Monthly Transaction/Points/Amount (Accruals, Reversals, Redemptions) * Customer Outstanding Points Report * Monthly Cancelled Points Report * GL+1 Approval Summary with Workflow * Miles Exchange Report (JAL Miles) * Daily Transaction/Points/Amount Report *** ## Audit & Compliance * **User reactivation** now captured in the Audit Trail for locked and archived accounts * **Tier Retention Period** configuration changes are now logged with user, action, and timestamp * **Referral Module** audit trail now captures changes to Referral Conditions and the Code Generation Toggle * **Report file transfer** to Azure blob storage now includes folder structure configuration and a minimum file size check (>1KB) *** ## Access Control ### Security Warning on Login (On-Premise / Private Cloud) * A configurable security disclaimer can be displayed on the login screen * The feature is **disabled** for public cloud deployments and only available for on-premise or private cloud clients # v7.21 — November 2025 Source: https://help-loyalife.xoxoday.com/release-notes/v7-21 Loyalife v7.21 introduces Pay with Rewards APIs, cashback issuance APIs, six new custom reports, DateTime support, regex pre-processing, and member activity codes. # v7.21 — November 2025 **Released:** November 2025 ## Pay with Rewards ### Redemption APIs Four new APIs for managing Pay with Rewards redemptions: **Create Redemption** * Member must have sufficient, positive points — requests with zero or negative balances are rejected * Eligible member statuses: Active only — Inactive, Suspended, Cancelled, and Membership Blocked members are rejected * Member cannot have an existing active redemption request * Points cannot exceed 11 digits * `ValidityPeriodInDays`: defaults to 3 days if 0 or not passed; otherwise uses the specified value (maximum 90 days) **Cancel Redemption** * Only requests with **Pending** status can be cancelled * Processed requests cannot be cancelled **List Redemption** * View requests across all statuses or filter by a specific status * Passing `status=0` returns all statuses **Get Redemption** * Fetch a specific request by ID to view the current status and details ### Cashback Issuance APIs Three new APIs for cashback management: **Create Cashback** * Mandatory inputs: ProgramId, RelationReference, Points, RewardType * Member must have sufficient point balance * The cashback request is written immediately with **Pending** status and processed end-of-day via an automated cron job, which changes the status to **Processed** * Points must be integers; decimal values are not accepted * An optional **Description** field can be stored but is not included in the JSON output file **List Cashback** * Filter by Status (passing `0` returns all), RecordsPerPage (defaults to 10), and PageNumber * Cashback entries **do not support cancellation or expiration** **Get Cashback** * Fetch a specific cashback record by CashbackId ### File Generation for Pay with Rewards / Direct Cashback * File name format: `YYYYMMDDHHMMSSCashBackFileGeneration.json` * Accrual transactions **after** a redemption request are considered for matching (sorted by date/time); transactions before the request are ignored * Decimal point values are treated as spoilage * `"Debit by redemption"` filter in transaction reports fetches both Pay with Rewards and Cashback records * Transaction code is `MP-MPAYM-G02` for all cashback transactions *** ## Data Processing ### DateTime Format Support * APIs and file uploads now accept datetime values in `YYYY-MM-DD HH:MM:SS` format * If only a date is passed (`YYYY-MM-DD`), it is stored as `YYYY-MM-DD 00:00:00.000` * Date-only pickers remain in the UI; a time picker is not implemented ### Regex Pattern Matching in Pre-Processing * Trims whitespace from customer transaction and CPD files * Converts date formats (ddmmyyyy / mmddyyyy) to the standard `yyyy-mm-dd` format (time cannot be changed via pre-processing) * Handles other transformations such as preferred language code conversions ### Handback File Enhancements * Success logs are now included in handback files for both TXN and CPD file types * TXN files: error code is hidden; only the detailed error message is shown * CPD files: both error code and error message are visible *** ## Reports ### Six New Custom Reports **Redemption Report** * Available under Reports → Custom Reports with flexible date range selection * Requires a `bin_number` attribute in member attributes * Exposes `cash_equivalent_points` from redemption transaction data as *Purchase Points Used* * *Earned Points Used* is automatically computed as Total Points Redeemed minus Purchase Points Used **Maker-Checker Add/Remove Points Report** * Monthly report generated on the 1st of each month (previous month's data) * Captures Checker ID (approver or rejector) and Description (merchant name) * Status shows **Pending** if the request is still with a checker or approver * *Decision Time* is blank for pending requests * Supports manual generation via custom start/end date **Member Audit Report** * Monthly report generated on the 1st of each month (previous month's data) * Requires a `bin_number` member attribute (string, non-mandatory/non-unique); appears as null if empty * Fixed columns: Member ID, Bank Identifier, Activity, Date, Time, IP Address, Device/Browser **Bonus Report** * Pulls data from three sources: BNS file transactions, manual bonus additions, and miscellaneous point debits * Columns: Member ID, BIN, Creation Date, Bonus Points, Bonus Type, Narration, Description * Supports custom Start/End Date parameters and monthly scheduling **Points Movement Summary (MTD)** * Monthly report showing point movements from the 1st to the last day of the month * Columns: Member Relation Reference, Date Range, Opening Balance, Accrued Miles, Redeemed Miles, Expired Miles * Includes adjustment columns for Bulk Upload and Manual Add/Remove modifications * Closing Balance reflects the last day of the month **Custom Summary Report** * Per-member summary columns: Member ID, BIN, Last Update, Status * Point breakdowns: Purchase Points (Type 4), Bonus Points, Earned Points (excluding Type 4), Redeemed Points * Totals: Total Points Available, Total Purchase Points Available, Total Earned Points Available ### Custom Date Range Generation * A new **Generate** button in the Custom Report module allows data generation between two specified dates * Admin users create reports; users with "Create Report" permission can share, delete, and generate; users with "View Report" permission can only view, generate, and download *** ## Manual Points ### Narration Prefix for Manual Adjustments * All transactions created via Add/Remove Points now include the prefix **"Manual Adjustment"** in the narration (e.g., *"Manual Adjustment – Bonus Points"*) * Existing narration values are preserved but prefixed * The updated narration is visible in Transaction Summary, Exports, and Reports * Users can filter by *"Manual Adjustment"* to isolate manual entries ### Maker-Checker Comments * When maker-checker is enabled, the maker can add comments during an Add/Remove Points request * Comments appear in the maker-checker request description (not in the approval section) * Audit trail captures verifier and approver comments, not maker comments *** ## Member Activity ### New Activity Codes The following activity codes are now available in the LBMS database: | Activity | Code | | ---------------- | ---- | | Pay with Rewards | 168 | | Points Transfer | 169 | | Cashback | 170 | | Sport Booking | 171 | | Sport Search | 172 | | Sport Details | 173 | * Activities are passed via the `InsertMemberActivityWithSessionID` and `InsertMemberActivity` APIs * Activities are exportable via the Member Activity export feature # v7.22 — December 2025 Source: https://help-loyalife.xoxoday.com/release-notes/v7-22 Loyalife v7.22 introduces tier bonuses for skipped tiers, pre-structured content for 15 languages, preferred language standardisation, unified CPD upload logging, and expanded points expiry visibility. # v7.22 — December 2025 **Released:** December 2025 ## Tiers ### Bonuses for Skipped Tiers Tier upgrade logic has been enhanced to award bonuses for all intermediate tiers that are skipped during an upgrade: * **Bronze → Silver:** Silver bonus credited * **Silver → Platinum (skipping Gold):** Both Gold and Platinum bonuses credited * **Re-upgrade after downgrade:** A member downgraded to Silver and later upgraded to Platinum receives bonuses for Gold and Platinum * Members can receive tier bonuses multiple times across these upgrade scenarios *** ## Multilingual Support ### 15 New Languages Pre-Structured The platform now pre-creates all required content structures for 15 additional languages: **Supported languages:** Spanish, Portuguese, French, Russian, Indonesian, German, Turkish, Dutch, Italian, Thai, Swedish, Danish, Irish, Polish, Finnish * English remains the default language; all content keys are available across all 15 languages * API error messages remain hardcoded in English * Language names display in English; country flags represent each language selection ### Preferred Language Standardisation Programs can now configure up to 15 secondary languages for member communication templates: * Once all 15 secondary languages are configured, the language list becomes **read-only** to maintain consistency * Communication templates can be created in all secondary languages * Members with a language not in the configured list are excluded during CPD upload or API processing * English is always the primary/default fallback *** ## File Processing ### Unified CPD Upload Log View CPD file upload logs now show **both successful and failed records in a single view**: * Previously, users had to check multiple sources to understand upload outcomes * All records with their respective statuses are now visible in one place *** ## Points Expiry ### Expiry Date Visibility on Member Dashboard Members can now view point expiration details directly on their dashboard alongside their total available points: * Expiry details are visible for **the current year plus the next 3 years** (up to 4 years total) * Points set to expire more than 5 years out are not displayed until the calendar advances into the 4-year window # v7.23 — February 2026 Source: https://help-loyalife.xoxoday.com/release-notes/v7-23 Loyalife v7.23 standardises decimal point calculations, expands transaction API capabilities, introduces role-based report sharing, and adds four new custom reports. # v7.23 — February 2026 **Released:** February 2026 ## Points & Calculations ### Decimal-Based Point Calculation Points are now calculated, stored, and reported using decimal values as the standard: * Rule engine computes points to 2 decimal places; stored with **1 decimal place** (single rounding applied at the second decimal) * **Ceiling rounding examples:** 13.68 → 13.70; 13.35 → 13.40 * **Floor rounding example:** 13.32 → 13.30 * Point spoilage displays up to 2 decimal places (e.g., 0.04) * Stored values are used consistently across balances and reports — no additional rounding occurs during display * **Historical data is not recalculated or migrated** **Modules affected:** Member balances, Reports, Rule Engine, Approval Workflow (time-bound rules), Dashboard accrual metrics, Transaction Amount, Redeem Points, Peer Transfer, API Transactions (Pay with Rewards, Cashback, BNS), Points Expiry, Communication credit events **Excluded modules:** Tier Bonus, Campaign Bonus, Manual Add/Remove Points, BNS Upload, Bulk Point Upload, Referral ### Accrual Reversal via Bulk Upload * Negative values in the upload file are accepted exclusively for accrual reversals * All other transaction types continue to require non-negative values * File handling updated from "Debit – Accrual Reversal" to "Credit – Accrual Reversal" *** ## Transaction API ### Additional Loyalty Transaction Types Parameter A new `AdditionalLoyaltyTxnTypes` parameter allows passing multiple loyalty transaction types in a single API call: * Values are comma-separated: e.g., `"AdditionalLoyaltyTxnTypes": "1,8"` * The system evaluates both `LoyaltyTxnType` and `AdditionalLoyaltyTxnTypes` together * Invalid or incorrect combinations return `ErrorCode 204: "No Transaction details are available"` * `LoyaltyTxnType` continues to accept only a single value *** ## Reports ### View All Generated Reports All report types are now accessible from a unified view — Auto-generated, Manual, Exported, One-time, Custom, and Shared: * Pagination adapts based on available data; horizontal scroll enabled when columns exceed viewport width * **Member search** is enabled when the report contains Member ID, Relation Reference, or Relation Reference fields * **Date filter** is enabled when the report contains Processing Date or Enrollment Date ### Empty Report Tabs Hidden * Report tabs (e.g., Transaction, Members) no longer appear when no data is available for that section * Users only see tabs with available report data ### Transaction Summary Default View * No automatic date range is pre-selected; the system displays the **latest 10 transactions** by default (most recent first) * Helper text shown: *"Showing latest 10 transactions. Select a date range to view more"* * When a date range is applied and results exceed 10 records, pagination activates (10 per page) ### Role-Based Report Sharing * Reports can now be shared at the **role level**, giving access to all users in that role * Individual user sharing continues to work as before * Reports shared to a role without "View Report" permission will only become visible once that permission is granted to the role ### Persistent Column Configuration * Column preferences in the Member Transaction Summary are saved per user * Configuration persists across logouts, browser refreshes, and session timeouts * Default columns for first-time users: Transaction Date, Transaction Amount, Transaction Type ### Four New Custom Reports * **Expiry Report** — member-level points expiry with columns for Member ID, BIN, Month, Year, Earning, Bonus Rewards, Rewards Expired, and Expiry Status * **Projected Expiry Report** — forward-looking version of the Expiry Report showing points expiring in future months (up to 3 years of schedule data) * **Detailed Customer Profile Report** — customisable profile columns with support for monthly and custom date-range generation * **Admin User Audit Report** — captures User ID (email), Activity, Date, Time, IP, Device, and Browser from the Loyalife audit trail; supports monthly and custom generation *** ## Security ### BDI Credential Encryption * Client credentials (Client ID, Secret Key, Access Token, Refresh Token) are now encrypted using **SHA-256** *** ## Access Control ### Advanced Configuration Permissions * Advanced Configuration is now restricted for default roles: **Program Admin**, **Program Manager**, and **Customer Executive** * User-created custom roles continue to show the Advanced Configuration permission *** ## Rule Engine ### Dynamic Segment Linkage with Rule Groups Rule Groups can now be linked to **Dynamic (Smart) Segments** for automatic member eligibility: * When a member attribute changes (e.g., tier upgrade), a MemberProfileUpdated event triggers the Segment Evaluation Service * The service re-evaluates members against linked segments and updates membership automatically * Members become eligible or ineligible for associated Rule Groups without manual intervention * **Constraint:** Once a segment is configured to a Rule Group, it cannot be changed *** ## Additional Improvements * **MemberActivation API** now returns specific error messages per scenario (e.g., *"Member is already active"*, *"Member is suspended"*, *"Member is cancelled"*) instead of generic errors * **BNS and CRD email notifications** now include an error log link so recipients can view failure reasons directly from the notification * **Disabled template display** in campaigns: disabled templates appear in a locked state with the tooltip *"This template is disabled and cannot be selected"* * **Inactive Rule Groups** (time-bound, expired): editing is now prevented; groups appear as read-only with an expiry message * **Cashback requests**: no daily limit — multiple cashback requests are allowed per day as long as sufficient points are available; existing *Pay with Rewards* restriction (one active request at a time) is unchanged * **Max Points field** now enforces integer-only input; decimal values (e.g., 10.50) are rejected * **Loyalife branding** is now optionally hideable at environment and program level via a configuration toggle # v7.24.0 — March 2026 Source: https://help-loyalife.xoxoday.com/release-notes/v7-24 Loyalife v7.24.0 introduces multi-destination SFTP cashback routing, flexible billing cycles, real-time reporting, gamification stock controls, and security hardening. # v7.24.0 — March 2026 **Released:** March 2026 · Sprint 64 ## SFTP & Transaction Management ### Multiple JSON Destinations for Cashback Files Cashback files can now be routed to separate destinations based on transaction direction: * **Credit Cashback** files route to the `GIIFT LOYALTY CBS DEBIT\Outbound` folder * **Debit Cashback** files route to the `Loyalty\Inbound` folder * **Pay by Rewards** files use the Credit Cashback folder * Applies to new files only; existing file routing is unaffected ### Transaction Status Lookup The transaction status API now requires both `transaction_id` and `program_id` as mandatory parameters: * Supports multiple narration types: Bonus, Peer-to-Peer, Redemption * Returns core fields: ID, Type, Amounts, Points * Relational fields (RelationType, CsData) are excluded from the response *** ## Core System ### Flexible Billing Cycles for Members Programs can now configure member billing on a **Calendar Month** or a custom **Billing Cycle** basis: * Custom cycles require a mandatory member attribute set to a reset date between 1 and 31 * Two new fields are available per member: **Current Cycle** and **Remaining Days** * Point capping limits reset in alignment with each member's individual billing cycle — not the calendar month ### End-of-Cycle Rewards * Automatic point or voucher issuance triggers post-cron, driven by program-level configuration * Calculation timing is determined per program settings ### Attribute Aggregation at Transaction Level * Aggregation now processes row-by-row at the transaction level (previously batch-level) * Supports **Rolling Year** calculations across Sum, Min, Max, Average, and Count functions ### Gender Options Expanded * The gender field now accepts three values: **M** (Male), **F** (Female), and **O** (Other) *** ## Reporting ### Consolidated Report Interface * Primary reports and exported data are unified under a single interface * **Real-Time View** enables live previews of Transaction, Member, and Communication report data before generating ### Custom Report Labels * Users can assign custom display names to report columns * Column order is adjustable via drag-and-drop ### Persistent Column Preferences * Column visibility configurations are saved per user and persist across sessions, browser refreshes, and logouts *** ## Gamification ### Scratch Card Stock Validation * Before allocating a scratch card, the system validates **Current Stock + Probability** to prevent over-allocation * Allocation is atomic — stock is decremented immediately to prevent inventory from going negative ### Game Search * Real-time search by game name is now available on the game listing screen ### Referral Tracking with AppsFlyer OneLink * The referral system integrates with AppsFlyer OneLink for tracking referral-driven installs and activations *** ## Security & Performance ### Authentication API Rate Limiting * Rate limits are applied to authentication APIs to protect against abuse * Tokens are automatically invalidated when rate limits are exceeded ### Cross-Domain URL Restrictions * Access to cross-domain URLs has been restricted as part of annual penetration testing remediation # v7.25.0 — June & July 2026 Source: https://help-loyalife.xoxoday.com/release-notes/v7-25 Loyalife v7.25.0 ships realtime V2 earn API improvements, SAML SSO, custom branded mobile app UI support, configurable aggregate computation timing, push notifications in campaigns, segment redesign, AG Grid custom reports, rule engine operators, and security hardening. # v7.25.0 — June & July 2026 **Released:** June & July 2026 ## Realtime Earn API (V2) ### Per-Transaction Identifiers in Response The V2 batch transaction API now returns a `request_id` for every transaction submitted in a batch. This server-assigned identifier can be used for support tracing and cross-referencing with the polling API. ### Polling API — Status Breakdown The polling API now returns a full status breakdown for a submitted batch: | Status | Meaning | | ------------------- | --------------------------------------------------------------------------------------------------------------------------------- | | **Success** | Transaction processed and points awarded | | **Pending** | Transaction queued, awaiting rule engine evaluation | | **Failed** | Transaction rejected — duplicate idempotency key or processing error | | **On Hold** | Transaction flagged by fraud prevention — awaiting admin review | | **Partial On Hold** | One or more rule groups are on hold (time-bound rule or fraud detection on a specific group); remaining groups processed normally | The polling response also includes the **total points awarded** for each transaction across all applicable rule groups. *** ## Authentication & Security ### SAML 2.0 SSO Enterprise programs can now enable **SAML 2.0 Single Sign-On** as an alternative to password-based login: * Supported identity providers: **Okta** and **Microsoft Azure AD** * Users are redirected to the IdP for authentication; Loyalife issues a session token after successful SAML verification * Disabling the SAML SSO toggle immediately reverts all logins to standard username/password * **LDAP** authentication continues to work when SAML is concurrently enabled * MFA is compatible with both SAML and LDAP flows ### Custom Subdomain Hosting Each program can be hosted on a dedicated custom subdomain instead of the shared default domain: * Custom subdomains are provisioned through **Program Settings → Program Details** * The subdomain URL is preserved across Login, Forgot/Reset/Setup Password flows, and all system-generated emails * Programs with SSO enabled cannot change their subdomain after configuration * Linked programs inherit the primary program's subdomain and logo * Custom subdomain URLs now route users directly to the correct login screen — SAML-only or dual-mode (Email/Password + SAML) — bypassing the program selection screen entirely * The post-login program switcher remains available for users with access to multiple programs * Subdomain creation events are now logged in the Subdomain URL audit trail ### API Credential Management Multiple Client ID and Client Secret pairs can now be generated per program: * **Module-level API keys** support Read or Write access scopes * Default credential expiry: **90 days**; custom expiry can be set up to a maximum of **2 years** * The credential listing shows **Expiring Soon** and **Expired** status badges * Automated email notifications are sent at: credential generation, revocation, 7 days before expiry, 1 day before expiry, and on the expiry day ### VAPT 2026 Security Hardening All vulnerabilities from the 2026 security audit have been resolved: * **SQL Injection (High):** Member search now uses parameterised queries; free-text input is rejected for all search parameters * **IDOR — Profile Disclosure (Medium):** Profile endpoint enforces server-side authorisation; cross-user access returns HTTP 403 * **Session Hijacking (Medium):** All active sessions and refresh tokens are invalidated on successful password reset * **CAPTCHA Misconfiguration (Medium):** Password reset endpoint now validates CAPTCHA server-side with per-IP and per-email rate limiting; expired tokens are rejected; abuse returns HTTP 429 * **PII Masking (Low):** Phone numbers and email addresses in member API responses are now masked at the serialiser layer * **Secure Media Access:** Media files are now served via encrypted proxy URLs instead of raw storage URLs; direct storage access is blocked *** ## Campaigns ### Push Notifications in Campaigns **Push Notification** is now a first-class delivery channel in the Campaign module alongside Email, SMS, and WhatsApp: * Supported campaign types: Promotional, Occasion Reward, and Reward to Members * Campaigns link to a push notification template from the Communication module * Campaign performance metrics show: Total Sent, Success, and Failed counts per notification * Notifications are delivered after the campaign cron executes ### Rule-Based Campaigns A new **Campaigns (Rule Based)** module is available, controlled by a program-level feature flag: * When enabled, rule-based campaigns appear in the Campaign module * The toggle is independent of the standard Campaigns module and defaults to OFF * Maker-Checker support for rule-based campaigns will be added in a future release *** ## Communications ### Push Notifications as a Channel Push Notification is now a 4th delivery channel in the Communication module: * **Title:** up to 50 characters * **Body:** up to 120 characters, supports `{{variables}}` for personalisation * **Redirect to screen:** optional deep-link target for the in-app screen that opens on tap * A live iPhone lock screen preview is shown in real time while composing * Test notifications can be sent to a registered member's device by phone number ### Notification Event Name Updates Legacy notification event names have been updated to clean, Loyalife-branded names. The `lbms_` prefix has been removed from all event names, and the Giift brand name has been replaced with Loyalife throughout. Existing client-customised templates are not affected by this change. *** ## Mobile Applications ### Custom Branded App UI Support Channel partner mobile apps can now be delivered with a fully custom, client-branded UI — covering login, home, points history, claim submission, KYC, and profile flows — as an alternative to the standard Loyalife channel partner experience. ### CamScanner-Grade Document Scanning Invoice and KYC document capture now uses the OS-native document scanner instead of a custom camera implementation: * **iOS:** Apple VisionKit · **Android:** Google ML Kit * Automatic edge detection, deskew (perspective correction), and image enhancement — fully on-device, no network dependency ### Re-KYC Flow Members who have already completed KYC can now re-initiate verification from their profile, with support for multiple KYC document types. *** ## Program Settings — Calculation ### Aggregate Computation Timing (Pre / Post) A new one-time, irreversible switch lets programs choose whether aggregate attributes are computed **before** or **after** rule execution: * Default: Pre Computation, applied to both new and existing programs * Switching from Pre to Post requires confirmation via a modal and cannot be reversed once confirmed * For Debit transactions, aggregate attributes update before rule execution; for Credit transactions, they update after — AVG, MIN, and MAX aggregate behaviour is unchanged * Validated across 40 scenarios, including MCC group exclusion, aggregate boundary testing, max points cap enforcement, and billing cycle aggregate reset ### Billing Cycle Toggle Made Irreversible The Billing Cycle switch under Program Settings is now a one-time, irreversible setting — a confirmation modal warns before enabling it. Max Points reset now aligns with the billing cycle reset logic. *** ## Billing Cycle Rewards ### Reward Calculation on Cycle End Date (Phase 1) Reward and aggregate calculations now trigger on the **Billing Cycle End Date** itself, rather than End Date + 1: * **Transaction Processing Date** is now the key date used for both reward and aggregate calculations * Members enrolled mid-cycle correctly exclude transactions dated before their enrollment date *** ## Segments ### Smart Segment and Manual Segment Creation Paths The segment creation flow now offers two distinct paths: * **Smart Segment** — filter-based, with support for Select All Members (static) or attribute-based filters. Segment name auto-populates; duplicate names are blocked; 100-character name limit applies * **Manual Segment** — CSV upload with append or replace mode; 100-character name limit applies ### Segment Listing Enhancements * Search by segment name from the listing page * Segment names are clickable hyperlinks * A **Linked Campaigns** column shows how many campaigns are associated with each segment ### Attribute Visibility Controls A dedicated **Attribute Flags** section is available in Feature Flags for segments: * 15 system attributes (across Member and Transaction categories) can be individually or bulk enabled/disabled * Disabling a system attribute hides it from the segment filter in the creation flow * Custom member and transaction attributes include an **Include in Segment Filter** checkbox, available at creation time and via Edit * Segment creation supports a mix of system and custom attributes without conflict *** ## Rule Engine ### "Is Multiple Of" Operator A new **Is Multiple Of** operator is available in Rule Engine conditions for aggregate attributes: * Applies to aggregate transaction count attributes * Enables milestone-based rules such as "every Nth transaction earns a bonus" * Example: `Monthly Transaction Count is multiple of 10 → award 100 bonus points` ### Attribute-to-Attribute Date Comparison Rule conditions can now compare two date-type attributes against each other: * Example: `Transaction Date [Day of Month] equals Date of Birth [Day of Month]` * Self-comparisons and comparisons between incompatible data types are prevented * Date-type fields are auto-locked in the comparison selector to enforce valid pairings ### Time Input for Transaction Date The Transaction Date attribute in Rule Engine and Campaign Rules now includes a **time picker (HH:MM, 24-hour format)**: * Default time is `00:00` if not set * The combined value is stored as `MM/DD/YYYY HH:MM` * For **Between** operators, each date boundary has its own time selector * Existing date-only rules are backward compatible — treated as `00:00` *** ## Reports ### AG Grid Search & Filter in Custom Reports Custom Reports now use **AG Grid** for real-time client-side search and filtering of CSV data: * Column headers are auto-detected from the CSV — no configuration required * **Filter types** are auto-assigned: text filter for strings, number filter for numerics, date filter for dates * **Global search** operates across all columns; column-level filters apply on top with AND logic * Multi-column filtering and filter reset are supported * Sorting available for string, numeric, and date columns * Pagination: 50, 100, 500, or 1,000 rows per page * **Filtered CSV export** — export only the rows matching your current filter state ### View Links in Custom Reports Custom reports now include clickable **View Segment** and **View Campaign** links that navigate directly to the relevant module detail page. ### Statement Summary File & Cashback SFTP Posting * A **Statement Summary** file is now generated automatically the day after each Billing Cycle End Date, listing opening balance, cycle-to-date earned/adjusted/redeemed points, and closing balance per member * A daily cashback file is posted automatically via SFTP to the configured financial posting destination * Numeric columns across custom reports no longer display thousands separators, and date filters use a consistent `YYYY-MM-DD` format *** ## Approval Workflow ### Summary Counters The Approval Workflow page now displays a **summary section** with real-time request counts: | Counter | Meaning | | -------------------- | -------------------------------------------------------------- | | **Pending Requests** | Requests pending with Checker + pending with Approver | | **Total Verified** | Requests verified by the Checker role | | **Total Approved** | Requests approved by the Approver (including direct approvals) | | **Total Rejected** | Requests rejected by either Checker or Approver | Counters update in real time as requests move through the workflow. Counts are role-level and module-specific. *** ## API ### LocalAttributes in GetTransactionSummary The `getTransactionSummary` API response now includes a `LocalAttributes` object for `transaction_type=1` (accrual) transactions: * All custom transaction attribute data types are returned: Int, String, Selection, Date, Float * For debit transaction types, `LocalAttributes` returns blank — no custom attribute data is populated * All other existing behaviour of the API is unchanged ### Redemption API — XID Parameter A new `XID` field is available on the Redemption API to support downstream reconciliation: * Passed in the request under `AdditionalDetail` and echoed back in the response * Stored against the redemption and populated in the Cashback Fin Posting file for reconciliation with external systems * If `XID` is omitted, redemption proceeds as before with `AdditionalDetail` returned as null *** ## UI & Navigation * **Sidebar collapsible toggle:** The left navigation sidebar now supports collapsing to icon-only mode. Hovering shows a tooltip label. Collapse state persists across sessions * **Program logo in top header:** The program logo dynamically reflects the currently active program * **Linked program switcher:** Accounts managing multiple programs can switch between them from the top header * **Admin login screen responsive:** The Admin Login screen is now responsive on Android and iOS mobile browsers in both portrait and landscape orientations * **Superset Dashboard on Loyalty Overview:** The Loyalty Overview page now displays the most recently created or updated Superset Dashboard; visibility can be toggled per program # v7.3.0 — January 2024 Source: https://help-loyalife.xoxoday.com/release-notes/v7-3 Loyalife v7.3.0 introduces member account closure, monthly e-statements, unified SFTP upload folder, transaction reversal via duplicate IDs, audit trail, and Minio object storage integration. # v7.3.0 — January 2024 **Released:** January 2024 ## Member Management ### Member Account Closure * Members created via CPD file are eligible for **immediate point expiry** upon closure; API-created members follow the program's configured expiry schedule * Points continue to be issued to closed/cancelled members when TXN or BNS files are processed * Closed/cancelled members **cannot** have points manually credited or debited from the UI * A closed or cancelled member can be reactivated directly without admin intervention if their CPD status is updated to active *** ## Communications ### Monthly E-Statements * Statements are calculated for the full calendar month (1st–31st of the previous month) * Communications are sent to **all members regardless of status or point balance** * The processing date is used to compute the metrics included in the statement * Backend-preloaded templates are used; template editing via the UI is not available *** ## File Processing ### Unified SFTP Upload Folder All file types (CPD, TXN, BNS) are now placed in a single **"Upload"** directory: * A common schedule processes all file types simultaneously * File naming rules: unique names across programs, case-insensitive, CSV format, files must end with their type extension (TXN/CPD/BNS) * Allowed characters: alphanumeric, hyphen, and underscore only * Files with mismatched naming conventions are picked up and processed based on column structure and data attributes * Duplicate or invalid filenames are picked up but not processed; they are visible only in the logs *** ## Transactions ### Reversal via Duplicate Transaction IDs * Transaction IDs are no longer required to be unique * Passing the same Transaction ID with `transaction_type = "CR"` triggers a reversal of the original transaction * Duplicate DR transactions with the same ID still award points if a rule matches *** ## Audit Trail A new audit trail captures user actions and page views per program: * Captures: user, action, page, timestamp, IP, browser * Program-specific; users mapped to multiple programs are tracked per program * **Not yet captured:** logout, login, reports, tier settings *** ## Communication Templates * New event templates added: Bonus, Accrual, Manual Bonus (Credit and Debit variants) * Disabled custom templates revert to the default system template * Templates support variables from Member and Transaction attributes *** ## Infrastructure ### Minio Object Storage Integration * Minio is now supported as a self-hosted object storage solution for cost-efficient and data-controlled storage * VPN access is required in non-production environments ### CDN Removal * All external JavaScript CDN references have been removed for compatibility with on-premise deployments # v7.4.0 — February 2024 Source: https://help-loyalife.xoxoday.com/release-notes/v7-4 Loyalife v7.4.0 introduces the 'For Every' rule condition, a transaction pre-processing layer, PII masking, rule and user archive/unarchive, and enhanced monthly statements. # v7.4.0 — February 2024 **Released:** February 2024 ## Rule Engine ### "For Every" Condition A new **"For Every"** condition type is available in rule creation: * **Data type:** Integer only; negative values are not permitted * When a product or group cap is reached, the resulting points are set to 0 (the rule still matches but does not award points) * Supports both **DR** (debit) and **CR** (credit) transaction types * Tier multipliers are now compatible with the "For Every" condition ### Transaction Pre-Processing Layer Programs can apply pre-processing transformations to TXN files before they enter the main rule engine: * Available for **TXN file uploads only** — TXN/Member/CPD APIs are excluded * Requires a `terminal_id` attribute configured as mandatory in the program * The combination of member reference + terminal ID can only appear **twice in a single file**; additional occurrences are ignored * Rejected records are flagged with failure status 4 and reported as *"rejected in preprocessing"* via email notification ### Rule Archive / Unarchive * Rules can be archived and unarchived; archived rules are hidden from the UI and excluded from processing * Rules must be unarchived before they can be edited *** ## Privacy & Data Protection ### PII Masking * Admins can mark any member attribute as **Personally Identifiable (PI)** * PI-tagged attributes are hidden from the UI by default; the *"Show PI Details"* privilege is required to view them * All access to PI attributes is recorded in the audit trail * **Known gaps (to be addressed in future releases):** Search, communication templates, segment filters, and maker-checker requests may still expose PII *** ## Reports ### PII Removed from Standard Reports * **Liability Report:** Member name and phone removed; email addresses are masked * **Members Report:** PII fields removed; new *"Activated Date"* filter added; *"Address"* filter removed; status values standardised * **Transactional Report:** PII removed; processing date updated to the cancellation date when a member is cancelled or closed *** ## User Management ### User Archive / Unarchive * Admin users can be archived and unarchived * Archived users cannot log in *** ## Monthly Statement * Transactions in monthly statements are now bucketed by type * New types tracked: Closed/Cancelled, Expired * Accrual is now split into **Spend Points** and **Bonus Points** *** ## Error Logs * Error file downloads are now available in Reports → Logs for CPD and TXN file uploads * BNS files and API-based records are not yet listed in the application *** ## API * **Member Add/Update APIs:** Error validations incorporated for data type mismatches and constraint violations * Email and mobile regex validation implemented for the Add API; pending implementation for the Update API # v7.5.0 — March 2024 Source: https://help-loyalife.xoxoday.com/release-notes/v7-5 Loyalife v7.5.0 introduces transaction queuing for unregistered members, structured member status flows, auto-generated legacy reports, and tiered communication priority handling. # v7.5.0 — March 2024 **Released:** March 2024 ## Transaction Processing ### Queuing for Unregistered Members * TXN file uploads and API calls are now accepted even without a matching member in the system * Transactions are stored and processed when a matching rule exists; they appear in reports and dashboards (excluding member reports) * When the member later onboards, the UI allows manual mapping of orphaned transactions * Stored transactions are excluded from segments, tiers, and campaigns until the member is created *** ## Member Management ### Structured Member Status Flow Five status values are supported in CPD uploads, with defined transition rules: | Code | Status | Description | | ---- | ---------- | --------------------------------------------- | | N | New | Initial onboarding; unique reference required | | B | Suspend | Active → Suspended | | C | Closed | Member closure | | A | Un-suspend | Suspended → Active | | U | Update | Demographic update; valid for any status | * Welcome emails are triggered on **first onboarding** or when a closed member is reactivated * Members activated via a new Member Activation API that accepts a relation reference parameter *** ## Reports ### Auto-Generated Legacy Reports Monthly system reports are now automatically generated for all programs: * **Accrual, Redemption, Expiry, Reversal, Cancellation, Bonus, Member, Communication** * The Member report is system-generated by default; custom reports continue to support variable time periods * New transaction report filters: Debit by Cancellation, Debit by Reversal, Credit by Reversal * The obsolete cashback filter has been removed *** ## Communications ### Priority Queue for Events Communication events are now classified into five priority levels for ordered processing: **Critical, High, Medium, Normal, Low** New communication events added: Redemption OTP, shop orders, flight/hotel bookings, package bookings, miles exchange, forgot password **Rate limiting:** * Configurable hourly limits per event/member * Daily limits per member **Template updates:** * Plain text character limit increased from previous to **2,000 characters**; HTML templates to **100,000 characters** * Special characters are allowed in templates *** ## Configuration * Session token expiry is now externally configurable via the `token_expiry` property * Timestamps throughout the application display as stored in the database — no timezone conversion is applied * Rule Engine selection dropdowns are restricted to existing valid values only # v7.6.0 — April 2024 Source: https://help-loyalife.xoxoday.com/release-notes/v7-6 Loyalife v7.6.0 enables maker-checker for user and role management, dramatically improves transaction report performance via MSSQL, adds a projected expiry report, and enables settings import/export. # v7.6.0 — April 2024 **Released:** April 2024 ## Maker-Checker ### User and Role Management Maker-Checker approval is now available for User and Role Management actions: * Activation at program level is **irreversible** — once enabled, it cannot be disabled * Covers: user creation, updates, and unlocking; excludes password resets and archiving * The UI shows each request's status: **raised**, **approved**, or **rejected** * When multiple requests exist for the same user/role, the latest accepted request takes priority * Bulk approval/rejection has been **removed** * Program-level summary emails are sent for pending actions *** ## Reports ### Transaction Report Performance * Report generation has been migrated to MSSQL * Performance: 1M records + 25 attributes previously took 30–40 minutes; now takes **1–2 minutes** * Deleted transaction attributes are automatically removed from reports without triggering errors * Custom reports now support an unlimited number of local transaction attributes ### Projected Expiry Report * A new monthly member-level report showing projected point expiry * Columns are customisable during program setup * Tested with: **10M members + 11M transactions over 1 year** — generation time \~45 minutes *** ## Role Management ### Dependent Permission Auto-Enable * When enabling certain permissions (e.g., *"Add/Remove Points"*, *"Suspend Member"*), the system automatically enables required dependent permissions (e.g., *"View Member"*) * Users can manually deselect these if needed after creation *** ## Import / Export ### Settings Transfer Between Programs * DevOps teams can transfer program settings between two programs **on the same LBMS version** * Exportable items: Member attributes, Transaction attributes, Attribute groups, Rules, Communication templates * Current limitation: Disabled/archived templates and rules are included in exports; future versions will export only active items *** ## Technical Improvements * Error log file processing migrated to MSSQL with a **30% reduction in processing time**, reducing load during large CPD/TXN uploads * All timestamps in the application now display based on **database/server time**; exported files use browser-based time *** ## Communications * Email template **title** is now optional for new templates (still required when editing existing templates) * Communication templates can be disabled to prevent default member notifications — members will not receive emails if all templates are disabled *** ## Bug Fixes * Resolved issue where emails were delivered to incorrect addresses; a patch has been applied to affected customers # v7.7.0 — May 2024 Source: https://help-loyalife.xoxoday.com/release-notes/v7-7 Loyalife v7.7.0 adds a member detail lookup API by any unique attribute, improves anomaly detection threshold management, and fixes SMS formatting. # v7.7.0 — May 2024 **Released:** May 2024 ## API ### Member Lookup by Unique Attribute A new API allows fetching member details using any unique attribute — not just the relation reference: * Supported attribute types: String, Integer, Decimal, Date * **Error conditions:** Returns an error if a non-unique attribute key is used, or if the attribute key or value doesn't exist *** ## Anomaly Detection ### Threshold Management * When a redemption threshold is updated, older records that no longer qualify are automatically filtered out and removed * Setting the threshold to **0** or deleting it **disables** anomaly detection for redemptions ### Flagged Transaction Behaviour * Rejected flagged redemptions: **no points are awarded**, but product and group limit caps are still updated * If a flagged transaction from a prior month is later approved, points are awarded based on the **previous month's cap limits** ### Scope Limitation * Anomaly detection applies to **accrual transactions only** * Excluded: Campaign Bonus, Tier Bonus, and Manual Bonus ### Decimal Points in Anomaly-Flagged Transactions * Only the **integer portion** of the point value is awarded to the member * The decimal remainder is marked as spoilage and is visible in reports *** ## Bug Fixes * **SMS formatting fixed:** Newline characters in SMS messages now render correctly, improving message readability # v7.9.0 — June 2024 Source: https://help-loyalife.xoxoday.com/release-notes/v7-9 Loyalife v7.9.0 significantly improves communication queue performance, adds member preferred language support, introduces data exports, and extends maker-checker to point configuration. # v7.9.0 — June 2024 **Released:** June 2024 ## Communications ### Queue Performance Optimisation The communication queue has been significantly re-engineered: * Payload size reduced from **17KB to 0.5–1.5KB** per job * Redis connection pool increased from 10 to 20; swap memory and memory thresholds introduced; job persistence enabled * A single pod can now process approximately **1 million communications** (at 100ms delay per email, \~3 days) * **Priority delivery:** OTPs and redemption confirmations bypass the standard queue for immediate delivery ### Communication Security * **Protected events** (OTP, forgot password, card redemption confirmation) have no preview option in the template editor * All emails are encrypted by default * Privacy controls apply equally to email and SMS templates *** ## Member Preferences ### Preferred Language per Member Programs can configure a default language for member communications: * Set at the program level for promotional and transactional templates * Once set, the preferred language **cannot be edited or removed** * Language can be updated for existing members via the Update Member API or CPD upload * When a member's preferred language is not set, or a template in that language is unavailable, English is used as the fallback *** ## Data Exports ### User, Role, and Audit Trail Exports * All users and roles are exportable globally (not program-specific) * Audit trail data is exported program-specifically to the Administrative Data section in Reports * Member activity logs (profile changes and member actions) are exportable at both member-specific and consolidated levels * Access requires View permissions for the relevant module *** ## Member Search ### Custom Attribute Search * Custom member attributes can be made searchable if *"Include in member search"* is enabled during attribute creation * Global attributes (Relation Reference, Full Name, Email, Phone Number) are always searchable * This setting is **immutable** once the attribute is created * Point information has been removed from the initial member search results to improve performance *** ## Maker-Checker ### Point Configuration Approval Point configuration changes now require maker-checker approval: * Once enabled at program level, this **cannot be disabled** * When multiple requests exist, the latest approved request takes precedence * Email alerts now include point configuration change requests * The Purchase Rate and Cashback Rate fields are removed from the edit UI (they may still appear during new program creation) *** ## CRD File Processing * RelationReference, LastSixDigits, Status, ProgramId, and ProductCode are now mandatory fields in CRD files * Product and sub-product codes are validated against system records * Duplicate sub-relation references are now accepted *** ## Reports * A new column tracks which user performed a member redemption * Point Purchase Report has been enhanced with additional tracking fields # Approval workflow Source: https://help-loyalife.xoxoday.com/user-guides/access-control/approval-workflow Learn how Loyalife's Maker-Checker workflow reviews and authorizes sensitive admin actions before they take effect. The Maker-Checker approval workflow adds a two-step review layer to sensitive administrative actions. A **maker** initiates a change; a **checker or approver** must review and authorize it before it applies. This prevents unilateral modifications to member accounts, program rules, or partner status, and provides a complete audit trail of every decision. ## Approval Workflow summary The top of the Approval Workflow page displays real-time summary counters for your role: | Counter | Description | | -------------------- | ----------------------------------------------------------------------------------------- | | **Pending Requests** | Total requests currently awaiting action — split between Checker queue and Approver queue | | **Total Verified** | Requests verified by the Checker role | | **Total Approved** | Requests approved by the Approver (including direct approvals by users with both roles) | | **Total Rejected** | Requests rejected by either Checker or Approver | Counters update in real time as requests move through the workflow. Counts are **role-level and module-specific** — they reflect the requests relevant to your role, not a program-wide aggregate. **Counter behaviour as requests progress:** * A Checker verifies → **Total Verified +1**, **Pending −1** * An Approver approves → **Total Approved +1**, **Pending −1** * Either role rejects → **Total Rejected +1**, **Pending −1** ## When the workflow applies The Maker-Checker process governs the following action categories, depending on your program's configuration: | Category | Actions covered | | ------------------------------ | ------------------------------------------------------------------------------------- | | **Manual point adjustments** | Adding or removing points from a member account outside the Rule Engine | | **Suspension actions** | Blocking, suspending, or re-activating a member | | **Business user management** | Locking, unlocking, archiving, or unarchiving an admin user | | **Member and user activation** | Activating a new business user or member | | **Onboarding requests** | Retailer or partner onboarding submitted from the partner app | | **Rule Engine changes** | Activating, modifying, or deactivating earning rules | | **Aggregate attributes** | Creating or updating aggregate attributes in the Rule Engine | | **Tier settings** | Changing the qualification method, point accumulation timeframe, or assessment method | | **Tier management** | Adding or modifying tier levels and their benefits | | **Point definition** | Changing points expiry settings or point calculation parameters | | **Campaigns (Rule Based)** | Creating or activating rule-based campaigns | | **Communications** | Creating or modifying notification templates | Automated transactions processed by the Rule Engine do not go through this workflow. The workflow only applies to manual or admin-initiated actions. ## The three roles | Role | Responsibility | | ------------ | --------------------------------------------------------------------------------------- | | **Maker** | Initiates the action — creates the request and submits it for review | | **Checker** | Verifies the request — reviews accuracy and adds remarks | | **Approver** | Final decision-maker — approves or rejects; the action only takes effect after approval | Roles are assigned in **Access Control → Manage Team → Roles**. A user can hold multiple roles, though this reduces the governance benefit. ## Request status codes Each request moves through the following statuses: | Status code | Label | Meaning | | :---------: | ----------------- | ------------------------------------------------------ | | 1 | Pending Checker | Request submitted by maker; awaiting checker review | | 2 | Pending Approver | Checker has reviewed; awaiting final approver decision | | 3 | Approved | Approver has approved; action has taken effect | | 4 | Rejected Checker | Checker has rejected the request | | 5 | Rejected Approver | Approver has rejected the request | ## Accessing the workflow Go to **Access Controls → Approval Workflow**. The module has three tabs: Approval Workflow screen showing Summary cards for Pending Requests (3), Total Verify (13), Total Approved (13), and Total Rejected (0), with Pending Actions tab active and a list of Member module requests with Request ID, Request description, Module badge, Raised On, and Description columns Approval Workflow All Status tab showing the same summary cards and a full request list with an additional Status column displaying Approved by Approver and Pending from Checker badges, plus a Raised By column | Tab | What you see | | ------------------------- | --------------------------------------------------------------------- | | **Manual Transaction** | Create a manual point adjustment for a specific member | | **Authorise Transaction** | All requests awaiting your review or approval (filtered to your role) | | **Functionality Master** | Configuration to enable or disable Maker-Checker for each module | The **Authorise Transaction** tab has two sub-views: | Sub-view | What you see | | ------------------- | -------------------------------------------------- | | **Pending Actions** | Requests awaiting your action | | **All Status** | Complete history — pending, approved, and rejected | ## Manual transactions The **Manual Transaction** tab lets authorized users create a manual point adjustment directly from the Approval Workflow module — without navigating to the member profile. ### Manual transaction fields | Field | Description | | ---------------------------------- | ---------------------------------------------------------------------------------- | | **Transaction Type (TT)** | 1 = Credit (add points), 2 = Debit (remove points) | | **Loyalty Transaction Type (LTT)** | The specific activity category — e.g., Bonus (2), Purchase (4), Miscellaneous (21) | | **Amount** | Transaction amount in program currency | | **Points** | Point value of the adjustment | | **Transaction Date** | Date to record for this transaction (can be backdated) | | **Expiry Date** | Optional expiry date for the points being credited | | **Product Definition** | The product category classification | | **Product Code** | Specific product code if the adjustment is tied to a product | | **Deal Code** | Deal or offer code if applicable | | **Transaction Currency** | Currency of the source transaction | | **Membership No** | The member's account or relation reference number | | **Merchant Name** | Merchant associated with the transaction | | **Transaction Code** | External transaction reference or code | | **MCC** | Merchant Category Code | Manual transactions created here go through the same Maker-Checker approval process as any other manual adjustment. The transaction is not posted until an approver authorizes it in the **Authorise Transaction** tab. ### Functionality Master The **Functionality Master** tab is where an administrator enables or disables the Maker-Checker requirement per module. Enabling a module means all changes to that module require approval. Disabling it means changes take effect immediately without a review step. | Module | Controlled by | | ------------------------- | -------------------------------------------- | | Manual Points | Functionality Master | | User Access (lock/unlock) | Functionality Master | | User Activation | Functionality Master | | Rule Engine | Functionality Master | | Point Definition | Functionality Master | | Tiers | Functionality Master | | Campaigns (Rule Based) | Functionality Master | | Communication Templates | Functionality Master | | Member Status Changes | Suspension Actions toggle (separate setting) | | Attribute Management | Functionality Master | | Reports | Functionality Master | ## Editing a pending request While a request is in **Pending** status, the maker can edit it before the checker or approver acts on it. 1. Open the request from **Pending Actions** or **All Status**. 2. Click **Edit** on the request. 3. Loyalife navigates you directly to the relevant module and field to make corrections. 4. Save your changes — the request updates in place without creating a new submission. Each request type navigates to the correct module when edited. For example, editing a Point Definition request opens the expiry settings; editing a Tier Settings request opens the tier qualification configuration. ## Onboarding requests When a retailer or partner submits a registration via the partner app, the submission enters the Approval Workflow as an **Onboarding Request**. This allows your team to review partner details, assign a category and role, and approve before the member account is created. ### Viewing an onboarding request Click **View** on any onboarding request to see: **Request metadata:** * Request raised by, module, current status, description **Partner details submitted from the app:** | Field | Description | | ----------------- | --------------------------------------- | | Full Name | Partner's full name | | Email Address | Registered contact email | | Phone Number | Mobile number | | Store Name | Business name | | Store Address | Physical location | | Pincode | Postal code | | PAN / KYC details | Identity documentation (where captured) | ### Approving an onboarding request Before approving, the approver must assign: | Required assignment | Options | | -------------------- | -------------------------------------------------- | | **Partner Category** | A1, A2, A3, B1, B2, or other configured categories | | **Role** | ASM, RSM, or other hierarchical role mapping | These assignments ensure structured retailer segmentation and correct role-based hierarchy mapping. **On Approve:** 1. Enter a mandatory reason for approval. 2. Confirm the action. 3. The member account is created immediately. 4. The selected category and role are applied. 5. Member status is set to Active. 6. An audit trail entry is generated. **On Reject:** 1. Enter a mandatory rejection reason. 2. No member account is created. 3. Status updates to Rejected. ### End-to-end onboarding flow ``` Partner submits registration via app ↓ Onboarding Request appears in Approval Workflow ↓ Maker verifies the request and submits remarks ↓ Approver reviews partner details ↓ Approver assigns Category and Role ↓ Approve → Member created & visible in Members module Reject → No member created; status = Rejected ``` ## Rule Engine changes When the approval workflow is enabled for the Rule Engine, the following actions require maker-checker authorization: | Action | What happens | | ------------------------------ | --------------------------------------------------------------- | | Activate a rule group | Rule group enters Pending; becomes live only after approval | | Deactivate a rule group | Deactivation requires approval before stopping point evaluation | | Modify earning rule conditions | Changes are staged until approved | ### Aggregate attributes Creating or modifying aggregate attributes (used for tier qualification or segment conditions) requires approval when the workflow is enabled for Rule Engine attributes: 1. Maker creates or edits the aggregate attribute and submits for approval. 2. The attribute appears in **Pending Actions** for the approver. 3. The approver reviews the formula, field references, and time window. 4. On approval, the attribute is immediately available for use in tiers and segments. ## Tier settings Changes to tier programme configuration that require approval: | Change | Why it requires approval | | --------------------------------------- | --------------------------------------------------------------------------------------------------------------------- | | **Qualification method change** | Switching from Points Only to Aggregated Attributes (or Both) affects all existing tier assignments | | **Point accumulation timeframe change** | Switching from lifetime to rolling — or changing the rolling window length — recalculates eligibility for all members | | **Assessment method change** | Switching from Automated to Manual assessment changes how the system updates tiers | Approval of a qualification method change triggers a system-wide re-evaluation of all member tier assignments. Test this change in a non-production environment first. ## Point definition changes Modifications to the points configuration — particularly expiry settings — require approval to prevent unintended changes to member balances: | Change | Covered by approval | | -------------------------------------- | ------------------- | | Expiry period configuration | Yes | | Expiry method (rolling vs. fixed date) | Yes | | Point calculation formula changes | Yes (when enabled) | ## Campaigns (rule-based) When Maker-Checker is enabled for campaigns: 1. A maker creates a rule-based campaign (targeting a segment with earn or reward rules). 2. The campaign enters **Pending** status — it does not activate or send communications until approved. 3. The approver reviews the segment targeting, earn conditions, and reward configuration. 4. On approval, the campaign becomes active on its scheduled start date. Standard (non-rule-based) campaign activation may have a lighter approval requirement depending on your program configuration. Check with your administrator which campaign types require full Maker-Checker review. ## Communications templates When Maker-Checker is enabled for communications: 1. A maker creates or edits a notification template. 2. The template enters **Pending** — it will not fire for any events until approved. 3. The approver reviews the channel content, variables, and trigger event mapping. 4. On approval, the template becomes active and starts firing for future events. ## Enabling the Suspension Actions toggle Under **Program Settings → Approval Workflow**, the **Suspension Actions** toggle enables Maker-Checker governance for: 1. Block, suspend, and re-activate a member 2. Lock, unlock, archive, and unarchive a business user 3. Activation of business users and members Once the Suspension Actions toggle is enabled, it cannot be reversed. Plan this configuration carefully before enabling it. ## Role permissions for approval workflow Configure who can act in each role under **Access Control → Manage Team → Roles**: | Module | Permission | Role function | | ------------------- | --------------------------- | ----------------------------------------- | | Onboarding Requests | Verify Onboarding Requests | Maker — can review and verify submissions | | Onboarding Requests | Approve Onboarding Requests | Approver — can approve or reject | | Manual Points | Submit Adjustment | Maker | | Manual Points | Approve Adjustment | Approver | | Suspension Actions | Submit Suspension | Maker | | Suspension Actions | Approve Suspension | Approver | | Rule Engine | Submit Rule Changes | Maker | | Rule Engine | Approve Rule Changes | Approver | | Tiers | Submit Tier Settings | Maker | | Tiers | Approve Tier Settings | Approver | | Campaigns | Submit Campaign | Maker | | Campaigns | Approve Campaign | Approver | | Communications | Submit Template | Maker | | Communications | Approve Template | Approver | ## Maker-Checker report The **Maker-Checker report** in Reports & Analytics provides a historical view of all approval workflow requests with their outcomes, timelines, and actors. | Column | Description | | ------------- | ------------------------------------------------------------------------ | | Request ID | Unique identifier for the request | | Module | Which module the request applies to (e.g., Manual Points, Tier Settings) | | Created by | The maker who initiated the request | | Submitted on | Date and time of submission | | Action | Approve / Reject | | Actioned by | The approver or checker who took the final action | | Campaign Name | For campaign requests, the campaign name | | Status | Current status | ## Practical example — manual point adjustment A member contacts support because their account was not credited for a qualifying purchase. 1. **Maker (support agent)** — opens the member profile, creates a manual point adjustment request with the transaction reference and point amount. 2. **Checker (supervisor)** — reviews the request, verifies the transaction reference, confirms the calculation is correct, and approves it to move forward. 3. **Approver (manager)** — reviews the checker's confirmation and grants final authorization. Points are credited to the member's account. ## Troubleshooting **A request submitted by a maker is not appearing in the approver's queue.** * Confirm the approver has the correct approval permission for that module in their role settings. * Check whether the request was accidentally rejected at an earlier stage. **An onboarding request is stuck in Pending.** * Verify there is an active user with the Approve Onboarding Requests permission. * Check if the Approval Workflow module is enabled in Program Settings. **A tier settings change is not taking effect after approval.** * If the change involves a qualification method switch, the system re-evaluates all member tiers — this may take several minutes for large programs. * Check the Audit Trail for the approval event confirmation. **The edit button is not visible on a pending request.** * Only the original maker can edit a pending request. * If you are the maker but cannot see the edit button, confirm the request is still in Pending status — once a checker or approver has acted, editing is no longer available. # Audit trail Source: https://help-loyalife.xoxoday.com/user-guides/access-control/audit-trail See Loyalife's tamper-evident audit trail, a chronological log of every admin action, showing who did what, when, and from where. The Audit Trail records every configuration change and administrative action performed in Loyalife. Each entry captures the actor, the action, the page, the timestamp, the IP address, and the browser. This gives your compliance, security, and operations teams a complete, non-repudiable history of how your program has been managed. ## What the audit trail captures The audit trail logs actions across all Loyalife modules. Common entries include: | Module | Examples of logged actions | | ----------------- | ------------------------------------------------------------------------------- | | Members | Status changes (suspend, block, activate), profile edits, point adjustments | | Rule Engine | Rule group activation/deactivation, rule creation, rule edits | | Tiers | Tier creation and deletion, milestone changes, tier retention period updates | | Segments | Segment creation, filter changes, rule group linkage | | Campaigns | Campaign creation, start/end date changes | | Communications | Template creation and edits | | Access Control | User invite, role assignment, user lock/unlock, password reset | | Approval Workflow | Request submission, approval, rejection | | Program Settings | Calculation method changes, decimal precision configuration, nomenclature edits | | Reports | Custom report creation, manual generation runs | ## Audit entry fields Each audit trail entry contains: | Field | Description | | ----------- | ------------------------------------------------------------- | | Date & Time | Timestamp of the action (shown in your configured timezone) | | Username | The admin user who performed the action | | Action | A human-readable description of what was done | | Page URL | The specific Loyalife page where the action occurred | | Activity | Detailed description — often includes before and after values | | IP address | The user's IP at the time of the action | | Browser | Browser and version used | ## Accessing the audit trail Navigate to **Reports & Analytics → Data Exports → Administrative Data** tab. Audit Trail screen showing a searchable log with Date, Username, Actions (e.g., Tier Edited, Tier Created), Page URL, Activity description, IP address, and Browser columns, with date range filter and Download button The Audit Trail is listed here and can be filtered and downloaded. Alternatively, some audit trail entries are visible directly within module detail views (e.g., the timeline on a claims management record). ## Key audit scenarios ### Tier retention period changes When an admin updates the Tier Retention Period — either toggling it on or off, or changing the duration — an entry is created: | Change | Activity logged | | ------------------------- | ------------------------------------------------------- | | Toggle Disabled → Enabled | "Tier Retention Period toggled from Disabled → Enabled" | | Toggle Enabled → Disabled | "Tier Retention Period toggled from Enabled → Disabled" | | Value change | "Tier Retention Period updated from 365 → 730 days" | ### Calculation setting changes When the calculation method (e.g., billing cycle) is changed in Program Settings, the audit trail captures: * The user who made the change * The previous calculation setting * The new calculation setting * Timestamp and IP ### User reactivation (locked or archived users) When a locked or archived admin user is re-added to the system: **At the Maker stage (when the request is submitted):** > "Request submitted to unlock/unarchive existing user \[username] for email \[email]" **At the Checker stage (when approved):** > "User \[username] unlocked" or "User \[username] unarchived" This replaces the previous misleading "User created" log message and makes the actual action clear in the audit record. If a duplicate email is detected at the Maker stage, an information message is shown: > "This email is associated with a locked/archived user. The existing user will be reactivated upon approval." ### Personal data access When an admin views the Personal Information section of a member profile, the access event is logged with the viewer's identity and timestamp. This provides accountability for access to sensitive personal data. ## Filtering the audit trail From the Administrative Data export view, filter audit entries by: | Filter | Options | | ----------- | ------------------------------------------------------- | | Date range | Custom start and end dates | | Username | Filter to a specific admin user's actions | | Module | Filter by the Loyalife module where the action occurred | | Action type | Filter by specific action categories | ## Exporting audit data Click **Download** to export the filtered audit trail as a CSV file. Exports include all fields listed above and are suitable for compliance reviews, security audits, and stakeholder reporting. ## Permissions | Action | Required permission | | ------------------ | ------------------- | | View audit trail | View Audit Trail | | Export audit trail | Export Reports | The audit trail is append-only — entries cannot be edited or deleted. This ensures the integrity of your compliance records. ## Compliance use cases **Internal audit reviews:** Filter by date range to export all admin actions during a specific review period. Cross-reference with role change history to verify separation of duties. **Investigating a configuration issue:** Filter by module and date to see every change made to a specific module. The before/after values in the Activity field identify exactly what changed and when. **Regulatory reporting:** Export audit records demonstrating that sensitive actions (member data access, point adjustments, approval decisions) followed defined workflows and were performed by authorized users. # Manage team Source: https://help-loyalife.xoxoday.com/user-guides/access-control/manage-team Invite users, assign roles, manage account status, and create custom permission roles for your Loyalife team. The Manage Team section gives program administrators control over who has access to Loyalife and what each person can do. It's split into two areas: **Users** and **Roles**. ## Accessing team management Go to **Access Controls** in the left sidebar. The Users tab is shown by default. Manage Team — Manage Users tab listing all admin users with Name, User Name, role, Date Created, Last Login columns and an Add New User button ## User management ### Inviting a user Click **Invite User**. Provide the user's name and email address. Select one or more roles for this user. Roles determine which modules they can access and what actions they can take. The user receives an email invitation with a link to set up their password and activate their account. Adding a New User modal showing User Information section with Email, Username, First Name, Last Name, and Phone fields, plus a Select a Role dropdown at the bottom ### Managing existing users From the Users list, open the three-dot Actions menu on any user to access management options: | Action | When to use | | ------------------ | ------------------------------------------------------------------------------ | | Edit user | Update name, email address, or role assignments | | Reset password | Trigger a password reset email for a locked-out user | | Lock account | Temporarily prevent the user from logging in | | Unlock account | Restore login access to a locked account | | Archive user | Remove a user who has left the organisation — their audit history is preserved | | Unarchive user | Reactivate a previously archived user | | Download user list | Export all users and their role assignments as a CSV | View User detail page showing User Information panel with Name, Email, Phone, and Role fields, followed by collapsible permission sections for User Access Management, Platform Configuration, and Member modules listing each granted action item ### Reactivating locked or archived users If an admin tries to invite a user with an email that belongs to a currently locked or archived account, Loyalife detects the duplicate and shows: > "This email is associated with a locked/archived user. The existing user will be reactivated upon approval." When the Maker-Checker workflow is enabled, this reactivation request enters the approval queue. The audit trail records: * At the Maker stage: "Request submitted to unlock/unarchive existing user \[username] for email \[email]" * At the Checker stage: "User \[username] unlocked" or "User \[username] unarchived" This prevents confusion with the previous "User created" message, which was misleading because the user already existed. ## Role management Roles define what a user can see and do. Every module in Loyalife has configurable permissions, and a role is a named bundle of those permissions. ### Viewing roles Click the **Roles** tab to see all existing roles. Manage Team — Manage Roles tab showing All Roles list with Role name, Access (X of 59 permissions), Number of Users, and Actions columns — displaying Customer Executive, Program Manager, Program Admin, and Super Admin roles Each role entry shows: * Which modules it grants access to * The permission level per module (View, Edit, Create) * How many users currently hold this role ### Creating a custom role From the Roles tab, click **Create Role**. Give the role a descriptive name that reflects its function — for example, "Claims Approver" or "Campaign Manager — View Only". For each module, select the permission level: | Level | Grants | | ------ | ---------------------------------------------- | | None | No access — module is not visible to this role | | View | Read-only access | | Edit | Can modify existing records | | Create | Full access including creating and deleting | Some modules have additional permissions beyond the standard levels. For example: * **Approve Assigned Invoices** — for Claims approvers * **Verify Onboarding Requests** and **Approve Onboarding Requests** — for the Maker and Checker in partner onboarding * **PI Data Access** — for exporting personally identifiable member data Save the role. It is immediately available for assignment when inviting or editing users. Creating a New Role modal showing Add Role Details section with Role Name and Role Description fields, followed by permission sections for Programs and User Access Management with individual toggle switches per action item The **Create** permission on most modules also grants the ability to delete. Review the specific module's permission details before assigning broad roles. ### Built-in roles Loyalife includes default roles that cover the most common team structures. These can be used as-is or cloned as a starting point for customisation. ### Downloading role reports Click **Download** from the Roles tab to export a CSV of all roles and their full permission configurations. Use this for internal access reviews, audit documentation, or onboarding new team members. ## Permissions reference | Action | Required permission | | ----------------------- | ------------------- | | Invite users | Manage Users | | Edit user roles | Manage Users | | Lock/unlock accounts | Manage Users | | Archive/unarchive users | Manage Users | | Create/edit roles | Manage Roles | | Download user list | View Users | # Access Control overview Source: https://help-loyalife.xoxoday.com/user-guides/access-control/overview Manage who can access Loyalife and what they can do with roles, permissions, approval workflows, and a full audit trail. Access Control governs every aspect of who can log in to Loyalife and what they are permitted to see or do. Loyalife uses a **role-based access model**: every user holds one or more roles, and each role carries a defined set of permissions across the platform's modules. ## Why access control matters | Goal | How access control helps | | -------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | | **Security** | Protects sensitive data — member PII, financial liability, transaction records — from unauthorized access | | **Governance** | The Maker-Checker workflow prevents any single person from making unilateral changes to member accounts, rule configurations, or partner onboarding | | **Compliance** | Every access and action is logged in the Audit Trail, providing a non-repudiable record for auditors and regulators | | **Efficiency** | Role-based permissions ensure users can complete their responsibilities without navigating unnecessary restrictions | ## Accessing Access Control Select **Access Controls** from the left sidebar. ## Modules within Access Control Invite users, assign roles, reset passwords, lock/unlock accounts, and create custom roles with granular permissions. Configure and manage the Maker-Checker process for point adjustments, member status changes, partner onboarding, and rule activations. Review a complete, tamper-evident log of every administrative action — who, what, when, and from where. ## Role structure Loyalife comes with built-in roles for common team functions. You can also create custom roles with any combination of per-module permissions. **Example role structure for a retail loyalty program:** | Role | Typical permissions | | ------------------ | -------------------------------------------------------------------- | | Customer Support | View Members, View Transactions — no edit access | | Marketing Manager | View and Create Campaigns, View Segments, View Communications | | Program Admin | Full access except Access Control management | | Compliance Officer | View Reports, View Audit Trail — read-only across all modules | | Super Admin | All permissions including User Management and Custom Report creation | ## Permission levels For most modules, permissions follow a hierarchy: | Level | What it allows | | ---------- | ------------------------------------------------------------------------------------------- | | **View** | Read-only access to the module — can see data but not change anything | | **Edit** | Can modify existing records (includes view access) | | **Create** | Can create new records, modify existing ones, and typically delete (includes view and edit) | Some modules have additional granular permissions — for example, **Approve Assigned Invoices**, **Verify Onboarding Requests**, or **PI Data Access**. ## Maker-Checker governance For sensitive actions — manual point adjustments, member status changes, partner onboarding — Loyalife enforces a two-step approval process: 1. A **Maker** initiates the action 2. A **Checker/Approver** reviews and authorises it before it takes effect This is configured in **Approval Workflow** and can be enabled or disabled per action type. See [Approval workflow](/user-guides/access-control/approval-workflow) for details. Once the Suspension Actions toggle is enabled in the Approval Workflow, it cannot be reversed. Plan this configuration carefully. # Advanced configuration Source: https://help-loyalife.xoxoday.com/user-guides/configuration/advanced-configuration Configure technical settings for personal data export controls, card/account linking, and CRD visibility in Loyalife. Advanced Configuration covers technical settings that affect data privacy capabilities and member profile linking. These settings are typically configured once at program setup and rarely changed afterwards. ## Accessing advanced configuration Navigate to **Configuration → Advanced Configuration → Technical Settings**. Advanced Configuration — Technical Settings tab showing Add Linked Loyalty Program section, Allow Export of Member PI Data toggle with description, and Enable accounts and card linking to Members toggle with expandable More Information section ## Member PI data export This toggle controls whether personally identifiable information (PII) can be included in member report exports. **What counts as PI data:** * Email addresses * Phone numbers * National identity numbers * Any custom member attributes that were flagged as PI during attribute creation ### Enabling PI data export Toggle the setting on in Technical Settings and confirm when prompted. This is a **one-way action**. Once the PI data export toggle is enabled, it cannot be disabled. All changes are logged in the Audit Trail. Enabling this feature allows bulk export of sensitive personal data. Ensure that only authorised administrators hold the export permission, and that exported files are handled in compliance with your organisation's data protection policies and applicable regulations (GDPR, DPDP Act, or similar). After enabling, administrators with the PI Data Access permission can include PI fields in member exports. The **Export Linked Accounts & Cards** option also becomes available with this permission. ## Customer relational data (CRD) — card and account linking CRD refers to external account or card information that can be associated with member profiles. This is used in programs where loyalty is tied to a financial product — for example, a credit card loyalty program where the card number is linked to the member's loyalty profile. **CRD fields available when enabled:** | Field | Description | | -------------------------------- | --------------------------------------------------------------------------- | | Card / account numbers | Credit card numbers, EMI account numbers, or other external identifiers | | Sub-relationship classification | The type of linked account or card (credit, debit, loan, etc.) | | Account status | Current status of the linked financial account | | Member relationship reference ID | The linking identifier between the Loyalife member and the external account | ### Enabling CRD visibility 1. Go to **Advanced Configuration → Technical Settings**. 2. Locate the **Enable accounts and card linking to members** toggle. 3. Enable it and confirm your selection. Once enabled: * The **View Linked Cards & Accounts** button becomes visible on member profiles (for users with the appropriate permission) * The **CRD search** option appears on the Members list, allowing admins to find members by card or account number * The **Export Linked Accounts & Cards** option appears in the member export menu (requires PI data access permission as well) ### Exporting CRD data Exporting CRD reports requires both: 1. **PI data access** permission in the user's role 2. **Report creation** capability in the user's role Exported files follow this naming convention: ``` Cards and Account Export [User Name] [Date].csv ``` The export includes: card numbers, sub-relationship classification, account status, and member relationship reference IDs. CRD export files contain sensitive financial identifiers. Apply the same data handling and storage controls as for other PII exports — encrypted storage, access logging, and retention limits per your data protection policy. ## Pre-processing logic The **Pre-Processing Logic** tab lets you deploy a custom script that transforms incoming data before the loyalty engine processes it. This is for programs that receive transaction files in non-standard formats or need field remapping before rule evaluation. Advanced Configuration — Pre-Processing Logic tab showing the pipeline diagram (SFTP Upload → Pre-Processing → Internal Engine → Loyalty Software) and a Pre-Processing Script editor with TXN and CPD tabs, a code editor panel, and Reset to Default / Save buttons The script editor supports TXN (transaction) and CPD (customer profile data) file types independently. Use **Reset to Default** to restore the original script if a custom transformation causes processing errors. ## Troubleshooting **The "View Linked Cards & Accounts" button is not visible on member profiles.** * Confirm the CRD linking toggle is enabled in Advanced Configuration. * Verify the viewing user has the CRD visibility permission in their role. **CRD search is not appearing on the Members list.** * CRD search requires the CRD linking toggle to be enabled in Advanced Configuration. **Export does not include PI fields even though the PI export toggle is enabled.** * Check that the exporting user's role includes the PI Data Access permission. * Verify that the specific fields you expect to see were marked as PI attributes during attribute creation. # MoEngage integration Source: https://help-loyalife.xoxoday.com/user-guides/configuration/moengage Sync loyalty events and member data from Loyalife to MoEngage to trigger personalised Push, Email, and SMS campaigns. The MoEngage integration connects Loyalife to your MoEngage workspace. Loyalife pushes loyalty events and member profile data to MoEngage every night via a scheduled sync. Your marketing team can then use that data in MoEngage to send Push notifications, Emails, and SMS messages — for example, a "You just earned points — redeem now" push the morning after a purchase, or a tier upgrade email when a member reaches Gold. ## How it works Every night at 12 AM, Loyalife runs a sync that sends two types of data to MoEngage: | Data type | What's sent | When | | ----------------------------- | ------------------------------------------------------------------------- | ---------------------------------------------------- | | **Loyalty events** | Event name, member identifier, points, earning type, transaction details | Nightly, for all events that occurred during the day | | **Member profile attributes** | Points balance, tier, enrollment date, activity metrics, expiry forecasts | Nightly, full refresh per member | Each record is matched to a MoEngage user profile using the member's **Relation Reference** — this becomes the **Customer ID** in MoEngage. Loyalife does not create new MoEngage profiles; members must already exist in MoEngage with the same identifier. Once the data lands in MoEngage, your team can build campaigns that trigger on any loyalty event or segment members by attribute — and send via Push notification, Email, or SMS. ## Enabling the integration In the Loyalife admin portal, navigate to **Program Settings → Integration** tab. Scroll down to the **MoEngage Integration** section and toggle it on. Program Configuration Integrations tab showing the MoEngage Integration section at the bottom with the toggle From your MoEngage dashboard, retrieve your **App ID** and **Data API key** under **Settings → APIs**. These are workspace-specific — use the credentials for the MoEngage account that holds your member profiles. The **Enable MoEngage Integration** modal opens. Fill in: * **App ID** — your MoEngage workspace identifier * **API Key** — the secret key for authenticating API calls to MoEngage * **Dashboard URL** — the MoEngage region dashboard URL that matches your account (e.g. `https://dashboard-01.moengage.com`) Enable MoEngage Integration modal with App ID, API Key, and Dashboard URL fields Click **Save**. The integration becomes active and data will flow on the next nightly sync. Treat MoEngage credentials as secrets. Do not share them or include them in exported configuration files. Rotate the Data API key in both MoEngage and Loyalife if it is ever exposed. ## Events sent to MoEngage The following loyalty events are included in the nightly sync: | Event | Trigger | | ------------------------------ | ------------------------------------------------- | | `loyalty_points_earned` | Points are credited to a member account | | `loyalty_points_redeemed` | Member redeems points in the marketplace | | `loyalty_points_expired` | Points expire based on the expiry schedule | | `loyalty_points_expiring_soon` | Expiry warning — 30, 60, or 90 days out | | `loyalty_tier_upgraded` | Member's tier increases | | `loyalty_tier_downgraded` | Member's tier decreases | | `loyalty_segment_entered` | Member qualifies for a segment | | `loyalty_segment_exited` | Member no longer qualifies for a segment | | `loyalty_redemption_reversed` | A redemption is cancelled and points are returned | | `loyalty_member_activated` | Member status changes to Active | | `loyalty_member_suspended` | Member is suspended | ### Points earned — earning types The `loyalty_points_earned` event includes an `earning_type` field that identifies the source of the credit: | `earning_type` | Source | | ---------------- | --------------------------------------------------------------------------- | | `accrual` | Points earned through a qualifying transaction evaluated by the Rule Engine | | `campaign_bonus` | Bonus points awarded by a campaign | | `manual_bonus` | Points manually credited by an admin outside of rule evaluation | | `tier_bonus` | Bonus awarded on a tier upgrade milestone | This lets MoEngage campaigns react differently depending on how points were earned — for example, sending a different message for a Rule Engine accrual versus a manual bonus. ## Member attributes synced The nightly sync updates the following attributes on each MoEngage user profile: **Point balances** | Attribute | Description | | -------------------------- | ----------------------------------------- | | `points_available` | Current redeemable points balance | | `points_accrued_lifetime` | Cumulative points earned since enrollment | | `points_redeemed_lifetime` | Cumulative points redeemed | | `points_expired_lifetime` | Cumulative points expired | **Tier and status** | Attribute | Description | | ----------------- | --------------------------------------------------------------- | | `tier` | Current tier name | | `status` | Member status (active, inactive, suspended, blocked, cancelled) | | `enrollment_date` | Date the member joined the program | **Activity metrics** | Attribute | Description | | -------------------------- | ------------------------------------------------- | | `last_transaction_date` | Date of the most recent point-earning transaction | | `total_transactions` | Total transaction count | | `days_since_last_activity` | Days elapsed since last transaction | **Expiry forecasts** | Attribute | Description | | --------------------- | ------------------------------ | | `points_expiring_30d` | Points expiring within 30 days | | `points_expiring_60d` | Points expiring within 60 days | | `points_expiring_90d` | Points expiring within 90 days | ## What you can do in MoEngage Once loyalty data is flowing, MoEngage campaigns can use it to trigger outbound messages across three channels: | Channel | Example use case | | --------------------- | ----------------------------------------------------------------------- | | **Push notification** | "You earned 150 points yesterday — you're 50 away from Gold" | | **Email** | Tier upgrade congratulations with a summary of new benefits | | **SMS** | Points expiry reminder: "Your 200 points expire in 7 days — redeem now" | Segment members in MoEngage using synced attributes (tier, points balance, days since last activity, expiry forecasts) to target the right audience before sending. ## Troubleshooting **Events or attributes are not appearing in MoEngage.** * Verify the App ID, Data API key, and data centre region are correctly saved in the integration settings. A mismatched region causes API calls to fail silently. * The sync runs at 12 AM — if you are checking shortly after a transaction or tier change, wait until the following morning. * Confirm the member's Relation Reference in Loyalife matches the Customer ID in MoEngage. Events are dropped if the user is not found. **A member exists in Loyalife but not in MoEngage.** * Loyalife does not create MoEngage profiles. The member must exist in MoEngage with a Customer ID matching their Loyalife Relation Reference before events will be associated with them. **Credentials have been rotated in MoEngage but events stopped flowing.** * Update the Data API key in **Program Settings → Integration → MoEngage** to match the new key. The sync will resume on the next nightly run. # Configuration overview Source: https://help-loyalife.xoxoday.com/user-guides/configuration/overview Explore Loyalife's platform configuration that covers organisation details, point definitions, calculation rules, and module toggles. Configuration is where you set the foundational parameters that govern how your loyalty program operates. These settings align Loyalife with your business requirements, brand identity, and operational processes. Most configuration changes are permanent or have significant downstream effects — review them carefully before saving. ## Accessing configuration Select **Configuration** from the left sidebar. Program Configuration screen showing the Organization Details tab active with Registered Business Name, Company Website URL, City, Region, and Country fields and an Edit button ## Configuration sections ### Organisation configuration Edit your company's details to keep business information current within the platform: Edit Company Details modal with fields for Registered Business Name, Company Website URL, City, Region, and Country with character count indicators and Update / Cancel buttons * Company name * Business address * Contact information * Organizational hierarchy settings ### Program details Manage and customize program-specific settings: | Setting | Description | | -------------------------- | --------------------------------------------------- | | Program name | The name shown to members and on all communications | | Currency | The base currency for your program | | Program status | Active, paused, or closed | | Program lifecycle settings | Enrollment open/closed, etc. | Program Configuration — Program Details tab showing Program Info section (Program Name, Base Currency), Program Nomenclature section, and Logo and Subdomain Configuration section with program logo upload and login URL subdomain field **On-premise deployments:** The Program Details page shows a **Logo Configuration** card instead of the Subdomain Configuration card. On-premise clients configure their program logo here, but subdomain assignment is not available — the login URL is managed at the infrastructure level by your IT team. #### Program Nomenclature Loyalife supports full UI text customisation through **Program Nomenclature**. Every string displayed in the member-facing app — labels, button text, messages, and error text — can be replaced with your program's branded language. **Accessing nomenclature:** Go to **Program Settings → Program Details → Program Nomenclature**. Use the module filter to view strings by page: | Filter | Shows strings for | | ------------ | ------------------------------------ | | Login | The login and sign-in screens | | Dashboard | The member home screen | | Transactions | The transaction history screen | | Rewards | The redemption and catalogue screens | | Profile | The member profile screen | Only string keys belonging to the selected module appear when a filter is applied. Keys from other pages (e.g., Reset Password, Compass navigation) are excluded from each filter to keep the list manageable. To change a label: find the string key, enter your custom text, and save. Changes apply to all members immediately. ### Point definitions Configure how points are structured and valued: Program Configuration — Point Definition tab showing Point Terminology and Rates section (Points Terminology, Cashback Rate, Customer Purchase Rate, Redemption Rate, Maximum Points Accrual Per Member Per Month), Decimal Precision section, and Expiration Details section | Setting | Description | | ------------------------ | ------------------------------------------------------------ | | Points-to-currency ratio | How many points equal one unit of currency | | Points naming convention | What your program calls "points" (e.g., Stars, Miles, Coins) | | Decimal precision | How many decimal places are used in point calculations | | Expiry policy | When and how points expire | | Rounding rules | How fractional points are handled | #### Expiry condition When configuring expiry, you specify whether points expire relative to: | Expiry condition | Value | Meaning | | --------------------------- | :---: | -------------------------------------------------------------------------------------------------------------------------------------------- | | **Processing Date** | 1 | Expiry is calculated from the date the points were posted to the member's ledger | | **Point Availability Date** | 2 | Expiry is calculated from the date the points became available for redemption (may differ from processing if a holding period is configured) | Choose **Processing Date** for programs where points become available immediately. Choose **Point Availability Date** for programs where points are held before posting. #### Decimal precision (important note) The decimal precision setting determines how many decimal places are stored and displayed in all point calculations across your program. **Once configured, this value cannot be changed.** This is intentional: changing decimal precision after transactions have been recorded would create inconsistencies in balances, reports, and member statements. Set this value correctly at program setup. Decimal precision is permanently locked after the first configuration. Plan this carefully before going live. If you need to change it, contact your Loyalife implementation team. ### Marketplace settings Configure the reward redemption options available to members: * Minimum redemption threshold (minimum points required to access the catalogue) * Available reward categories * Plum integration settings (redemption rate token configuration) * Redemption rate (points-to-currency conversion for redemption) ### Upload notifications Configure alerts for file upload events: * Who receives notifications for TXN file processing outcomes * Alert thresholds (notify when rejected row count exceeds X%) * Notification channels (email) * Which upload types trigger notifications ### Communication Set up messaging infrastructure: Program Configuration — Communication tab showing Sender Details section with Sender Name and Sender Email Address fields, and an Authenticate your Domain section with a Verify button for enabling custom domain sending * Sender email address and display name * SMS sender ID * Default reply-to address ### API integrations Manage third-party connections: Program Configuration — Integrations tab showing Marketplace Integration section with masked Client ID, Secret ID, Access Token, and Refresh Token fields, Custom Storefront URL section, and MoEngage Integration section with Active connection status and last event details * API keys for your systems integrating with Loyalife * Webhook endpoint configuration * Integration health status * Token management for partner integrations (e.g., Plum SSO token, Redemption Rate token) ### Modules Control which Loyalife features are active for your program: Program Configuration — Modules tab showing Approval Workflow section with toggles for Manual Points, User Access Management, Rule Configuration Approval, Point Approval for Time-Bound Rules, Campaigns and Communications, Campaigns (Rule Based), and Tiers modules | Module | What enabling it does | | ---------------- | ------------------------------------------------------------------------------- | | Referrals | Activates the Referrals module and auto-creates member referral code attributes | | Tiers | Activates the Tiers module for member tier assessment | | Fraud Prevention | Enables fraud threshold monitoring on transaction accrual | | Gamification | Enables the game creation and partner-facing games experience | Disabling a module hides it from the admin portal and stops its functionality without deleting historical data. ### Calculation settings Define computational rules for point processing: | Setting | Options | | ------------------ | --------------------------------------------------------------------- | | Calculation method | Transaction-date basis vs. billing cycle basis | | Billing cycle | Monthly, quarterly, or custom period (when billing cycle is selected) | | Processing timing | When points are posted after a transaction event | Changes to the calculation method are logged in the Audit Trail. Switching between transaction-date and billing cycle basis affects how aggregate attributes (like Monthly Spend Sum) are computed and may impact existing rule evaluations. Test in a non-production environment before changing a live program. ## SAML 2.0 SSO Enterprise programs can enable **SAML 2.0 Single Sign-On** as an alternative to password-based login under **Program Settings → Program Details**: * **Supported identity providers:** Okta and Microsoft Azure AD * When enabled, users are redirected to the IdP for authentication; Loyalife issues a session token on successful SAML verification * Disabling the SAML SSO toggle immediately reverts all logins to standard username/password * LDAP authentication continues to work when SAML is concurrently enabled * MFA is compatible with both authentication flows * Programs with SSO enabled cannot change their subdomain configuration after it is set Once a custom subdomain is saved, it is locked and cannot be changed. Programs with SSO enabled inherit this restriction. ## API Credential Management Multiple API credentials can be generated per program under **Program Settings → API**: * Generate multiple **Client ID / Client Secret** pairs, each with independent expiry * **Module-level API keys** support Read or Write access scopes * Default credential expiry: **90 days**; configurable up to a maximum of **2 years** * The credential listing page shows **Expiring Soon** and **Expired** status badges * Automated email notifications are sent at: credential generation, revocation, 7 days before expiry, 1 day before expiry, and on the expiry day * Rotating a credential generates a new pair — the old credential is immediately revoked ## Related See [Advanced Configuration](/user-guides/configuration/advanced-configuration) for PI data export controls and card/account linking settings. # Broadcast Campaigns Source: https://help-loyalife.xoxoday.com/user-guides/engage/broadcast-campaigns Push time-limited promotions to a defined member segment — bonus points, cashback, multipliers, and re-engagement offers. Broadcast campaigns are manually scheduled promotions that apply to a selected member segment during a specific time window. Use them to reward your best members, re-engage dormant ones, run seasonal offers, or test new incentive structures without permanently changing your base earning rules. ## Accessing campaigns Navigate to **Campaign Management → Broadcast Campaigns** in the left sidebar. Manage Campaigns screen listing campaigns with Campaign Name, Segments, Issued count, Campaign Type, Status columns and toggle controls to enable or disable each campaign ## What makes campaigns distinct from rules The Rule Engine defines your program's **baseline earning logic** — rules that always apply. Campaigns are **time-limited promotions** layered on top. A campaign starts on a specific date, ends on a specific date, and targets only members in a selected segment. When the campaign ends, earning logic reverts to the baseline. This separation means you can run aggressive promotions without permanently changing your core earning structure. ## Campaign components | Component | Description | | -------------- | ------------------------------------------------------------------------ | | Name | Internal label for the campaign | | Start date | Date from which the campaign incentive applies | | End date | Date after which the campaign no longer awards incentives | | Target segment | The member group this campaign applies to | | Incentive | What members earn for qualifying transactions during the campaign window | | Communication | An optional notification to alert members about the campaign | ## Creating a campaign The campaign creation form opens. Enter a campaign name and set start and end dates. * Start date must be today or a future date — you cannot create a campaign with a past start date. * End date must be on or after the start date. * Once a campaign is live (past start date), the start date cannot be moved to a future date. Choose the segment this campaign targets. Only members in that segment at the time of a qualifying transaction receive the campaign reward. Dynamic segments are evaluated in real time; Frozen segments use the membership snapshot from when the segment was created. Set what members earn for qualifying transactions during the campaign window: | Incentive type | Example | | ------------------- | ------------------------------------------- | | Bonus points (flat) | 500 bonus points per qualifying transaction | | Points multiplier | 2× points on all transactions | | Cashback percentage | 5% cashback on spends above ₹2,000 | | Custom benefit | Non-point reward configured externally | Before launching, preview the count and list of members who currently qualify based on the selected segment. Use this to validate targeting before going live. Attach a [Communication template](/user-guides/engage/communications) to notify members about the campaign. Members who know about the offer are significantly more likely to act on it. Review all settings and publish. The campaign becomes active on the configured start date. ## Qualified members view After a campaign is created, you can view members who qualify based on the linked segment: * A count of qualifying members * Individual member details * Cashback or reward data per member (useful for reconciliation and performance review) ## Schedule date validation | Rule | Detail | | -------------------------------- | -------------------------------------------------------------- | | Start date cannot be in the past | When creating a new campaign | | End date must be ≥ start date | Cannot end before it begins | | Live campaign start date | Cannot be moved to a future date once the campaign has started | These validations prevent creating campaigns that can never run or that retroactively claim to have started in the past. ## User permissions | Permission | What it allows | | ---------- | ---------------------------------------------- | | View | See campaign details and performance metrics | | Edit | Modify campaign settings, dates, and targeting | | Create | Create new campaigns and delete existing ones | ## Push notifications in campaigns Push Notification is now available as a delivery channel in campaigns alongside Email, SMS, and WhatsApp: * Link any active push notification template from the Communication module to a campaign * Supported campaign types: **Promotional**, **Occasion Reward**, and **Reward to Members** * Performance metrics per campaign show **Total Sent**, **Success**, and **Failed** counts for push delivery * Notifications are delivered after the campaign cron executes, not immediately on activation ## Rule-Based Campaigns **Campaigns (Rule Based)** is a separate campaign type available when enabled via a program-level feature flag under **Program Settings → Modules → Engage**: * The toggle is independent of the standard Campaigns module and defaults to **OFF** * When enabled, rule-based campaigns appear in the Campaign module alongside standard Broadcast campaigns * Contact your Loyalife administrator to enable this feature for your program Maker-Checker approval support for rule-based campaigns will be available in a future release. ## Troubleshooting **A member who should qualify is not receiving the campaign reward.** * Verify the campaign is Active (past start date, before end date). * Check that the member is in the target segment. Dynamic segments update in real time; Frozen segments use the snapshot from when the segment was frozen. * Confirm the qualifying transaction occurred within the campaign's start and end date window. **Campaign is not visible to a team member.** * Check their role permissions — they need at least View access for the Campaigns module. Points awarded by campaigns — broadcast or triggered — are recorded as **Credit By Bonus** entries on the member's ledger. To report on campaign-driven point awards, filter Transactional reports by [Credit By Bonus](/user-guides/reports/report-types#credit-by-bonus) and check the Narration column for the campaign source. # Communications Source: https://help-loyalife.xoxoday.com/user-guides/engage/communications Build and manage notification templates across Email, SMS, WhatsApp, and Push triggered by loyalty events or campaigns. The Communications module is where you build and manage all member-facing message templates. Templates fire automatically when a loyalty event occurs (transactional) or are dispatched by a campaign targeting a specific member segment (promotional). ## Supported channels | Channel | Provider | Details | | -------------------------------------------------- | ------------------------------- | --------------------------------------------------------- | | [**Email**](/user-guides/engage/email) | SendGrid (by Twilio) | Rich HTML; drag-and-drop editor; images, buttons, layouts | | [**SMS**](/user-guides/engage/sms) | Plivo (India); varies by region | Plain text; DLT registration required for India | | [**WhatsApp**](/user-guides/engage/whatsapp) | Configurable WABA gateway | Pre-approved templates only; template ID required | | [**Push**](/user-guides/engage/push-notifications) | Firebase Cloud Messaging (FCM) | Requires Loyalife mobile app installed on device | Each channel can be independently enabled per template. A single template can send across all four channels simultaneously. ## Template types | Type | How it fires | | ----------------- | ---------------------------------------------------------------------------------------------------------------- | | **Transactional** | Fires automatically when a specific loyalty event occurs — immediately, no scheduling required | | **Promotional** | Attached to a campaign; dispatched to a segment immediately on campaign activation or at a scheduled future date | ## Creating a template Manage Templates screen listing communication templates with Template Name, Events binding, Active Channels badges (Email, SMS, WhatsApp, Push), Total Sent count, and Success Rate columns, with Create Template button in the upper right Select **Transactional** or **Promotional**. This determines whether you pick a trigger event or link to a campaign. Pick the loyalty event that will send this message. Each event supports one active template per channel. Toggle on each channel — Email, SMS, WhatsApp, Push. Each has its own content section. See the per-channel pages for field requirements, character limits, and constraints. Leave blank to send immediately when the campaign activates, or pick a future date within the campaign window. If Maker-Checker is enabled for Communications, saving creates a pending approval request. The template does not go live until an approver authorises it. Create New Template form with Template Name field, Transactional type selected, trigger event dropdown showing Gift Card Redemption selected, Sensitive Data checkbox, and Setup Communication Channels section with Email, SMS, WhatsApp, and Push Notification channel toggles ## Trigger events ### Member lifecycle | Event | Description | | ----------------------- | ------------------------------------------- | | `member_activation` | Member account is activated | | `member_otp` | OTP sent for login or verification | | `two_factor_otp` | OTP sent for two-factor authentication | | `user_access_shared` | Admin user is invited to the program | | `role_modified` | A user's role is changed | | `pending_maker_checker` | A Maker-Checker approval request is pending | ### Points and transactions | Event | Description | | ----------------------- | ----------------------------------------------------- | | `points_accrual` | Points credited after a qualifying transaction | | `points_redeemed` | Member completes a redemption | | `point_reversal` | A previously credited transaction is reversed | | `points_expiring` | Points approaching expiry (triggered N days before) | | `points_expired` | Points have expired | | `bonus_points_credited` | Bonus points awarded (campaign, milestone, or manual) | | `gift_card_redemption` | Member redeems a gift card | ### Tier events | Event | Description | | ----------------- | --------------------------------------------------- | | `tier_upgraded` | Member's tier increases | | `tier_downgraded` | Member's tier decreases | | `tier_retained` | Member's tier is retained during a retention period | ### Referral events | Event | Description | | ------------------------- | ------------------------------------------------- | | `referral_completed` | A referred member completes the qualifying action | | `referral_bonus_credited` | Referral reward is credited to the referrer | ### Channel partner events | Event | Description | | --------------------- | -------------------------------------- | | `onboarding_approved` | Partner account approved and activated | | `onboarding_rejected` | Partner registration rejected | | `claim_approved` | Partner invoice claim approved | | `claim_rejected` | Partner invoice claim rejected | | `new_scheme_launched` | A new earning scheme is made available | ### Fraud and compliance | Event | Description | | ------------------------- | ---------------------------------------------------- | | `pending_fraud_review` | A transaction has been flagged and is pending review | | `redemption_fraud_review` | A redemption transaction has been flagged for review | Adding new custom events is managed by the Loyalife team during program setup and is not currently self-serve. ## Dynamic variables Use `{{variable_name}}` syntax anywhere in template content. Available variables: | Variable | Value | | ------------------------ | --------------------------------------------- | | `{{member_name}}` | Member's full name | | `{{points_balance}}` | Current points balance | | `{{tier_name}}` | Current tier name | | `{{points_earned}}` | Points credited in the triggering transaction | | `{{points_redeemed}}` | Points redeemed in the current transaction | | `{{expiry_date}}` | Date when points expire | | `{{referral_code}}` | Member's referral code | | `{{transaction_amount}}` | Transaction value that triggered the event | | `{{merchant_name}}` | Merchant where the transaction occurred | | `{{bonus_points}}` | Bonus points awarded in this event | | `{{program_name}}` | The loyalty program's name | | `{{otp}}` | One-time password (OTP events only) | ## Multi-language templates Each template supports a primary language and one or more secondary languages. Loyalife selects the correct variant at send time based on the member's **Preferred Language** attribute. Secondary language templates are configured per channel independently. ## Communication settings Communication Settings screen showing Email Branding Layout selector with template preview thumbnails, and Monthly E-Statements toggle for enabling automated member statements via email Navigate to **Engage → Communications → Settings** to configure program-wide communication preferences, including email branding layouts and monthly e-statement delivery options. ## Delivery history and resend From a member's profile, go to **Account Info → Communications** to see the full delivery log across Email, SMS, and WhatsApp. From this view you can resend any notification directly to the member or view the content of what was sent (hidden for templates marked Sensitive). ## Permissions | Permission | What it allows | | ---------- | ------------------------------------------------------- | | View | Review existing templates and delivery metrics | | Edit | Modify template content, variables, and scheduled dates | | Create | Create, modify, and delete templates | # Email Source: https://help-loyalife.xoxoday.com/user-guides/engage/email Send rich HTML emails via SendGrid with a drag-and-drop editor, personalisation variables, scheduling, and delivery analytics. Email is the most flexible channel in the Communications module. It supports rich HTML layouts, images, and buttons, with a visual drag-and-drop editor for building templates without writing code. **Provider:** SendGrid by Twilio ## Editor options | Mode | When to use | | ----------------- | ------------------------------------------------------------------------------------------------------------------ | | **Drag-and-drop** | Visual block editor (GrapeJS) — add text, images, buttons, dividers, and multi-column layouts without writing HTML | | **Raw HTML** | Paste or upload a pre-built HTML file for full control | Both modes support `{{variables}}` anywhere in the subject or body. You can switch between modes; switching to HTML preserves the rendered output. ## Configuration fields | Field | Required | Notes | | --------------------- | -------- | ----------------------------------------------------------------------------------- | | Subject line | Yes | Supports variables (e.g. `Hi {{member_name}}, you earned {{points_earned}} points`) | | Body / HTML | Yes | Full email content | | Header image | No | Displayed at the top of the email | | Call-to-action button | No | Configure button text, link URL, and colour | ## Previewing and testing The editor renders a live preview alongside the content editor. Switch between **Desktop**, **Tablet**, and **Mobile** views to verify layout at different screen widths. Use **Send Test Email** to dispatch the template to a specific member's registered email address. Variables are substituted with real data from that member's profile in the test send. ## Scheduling For **Promotional** templates, set a scheduled send date to delay delivery: * The date must be in the future at the time of saving * The date must fall within the linked campaign's active window * Leave blank to send immediately when the campaign activates **Transactional** templates always fire immediately when the trigger event occurs — scheduling does not apply. ## Delivery analytics Each template's detail view shows delivery metrics over selectable time windows (7 days, 30 days, 3 months, 6 months): | Metric | Description | | ---------------- | ---------------------------------------------- | | Total sent | Number of emails dispatched | | Delivered | Emails accepted by the recipient's mail server | | Failed / bounced | Emails that could not be delivered | ## Troubleshooting **Member is not receiving the email.** * Confirm the member's email address is registered and valid in their profile. * Check the template is Active and linked to the correct event. * Review the delivery log on the member's profile (**Account Info → Communications**) for bounce or failure status. * Ask the member to check their spam or junk folder — transactional emails from a new sender domain may be filtered on first receipt. **Template is not going live after saving.** * If Maker-Checker is enabled for Communications, the template enters Pending status and requires approver authorisation before it activates. - Include the member's name or a specific points figure in the subject line — these improve open rates. - Put the most important information and the call-to-action above the fold. - For points-expiry emails, send at 30 days and again at 7 days before expiry. - Test in both light and dark mode — header images should be legible in both. - Keep subject lines under 50 characters to avoid truncation in mobile inboxes. # Push notifications Source: https://help-loyalife.xoxoday.com/user-guides/engage/push-notifications Send mobile push notifications via Firebase Cloud Messaging (FCM) which has character limits, delivery signals, and test dispatch. Push notifications are sent to the **Loyalife mobile app** via **Firebase Cloud Messaging (FCM)**. They appear on the member's device lock screen or notification shade and can open specific in-app screens on tap. **Provider:** Firebase Cloud Messaging (FCM) ## Requirements For a member to receive push notifications: * The Loyalife mobile app must be installed on their device * The member must be logged in to the app * The member must have granted notification permissions on their device If any of these conditions are not met, the notification cannot be delivered. ## Configuration fields | Field | Required | Limit | Notes | | --------------- | -------- | -------------- | ----------------------------------------------------------------------------------------------------- | | Title | Yes | 50 characters | Shown on the lock screen and in the notification shade | | Body | Yes | 120 characters | Notification message; supports `{{variables}}` | | Redirect screen | No | — | In-app screen that opens when the member taps the notification; sourced from the program's App Config | ## Constraints | Constraint | Detail | | ---------- | ---------------------------------------------------------------------------------------------------------------- | | No links | External URLs are not supported in push notifications | | No images | Image attachments are not supported | | Logo | The icon displayed with the notification is the program's configured logo — it cannot be overridden per template | | Variables | Supported in the body field using `{{variable_name}}` syntax | ## Delivery and success Loyalife determines delivery outcome based on the FCM response: | Status | Meaning | | ----------- | -------------------------------------------------------------------------------------------------------------- | | **Success** | FCM accepted the message and returned no error — the device token is valid and the notification was dispatched | | **Failed** | FCM returned an error — the device token is invalid (app uninstalled, user logged out, or token expired) | A failed push cannot be recovered — Loyalife does not retry. The member must reinstall the app and log in to receive future push notifications. FCM does not confirm whether the member actually saw or tapped the notification — only that the message was accepted for delivery. Success means FCM accepted it, not that it was opened. ## Previewing and testing Use **Send Test Notification** to send a live push to a specific member's device: 1. Click **Send Test Notification** in the template editor 2. Enter the member's registered phone number — the system resolves the member 3. Variables in the body appear as fillable fields in the test modal 4. Submit — the FCM message is dispatched immediately The test sends the notification in real time and is not recorded in the member's delivery log. ## Delivery analytics Each template's detail view shows push delivery metrics over selectable time windows (7 days, 30 days, 3 months, 6 months): | Metric | Description | | ---------- | ---------------------------------------------- | | Total sent | Number of push notifications dispatched to FCM | | Success | Notifications accepted by FCM (valid token) | | Failed | Notifications rejected by FCM (invalid token) | A success/fail pie chart is shown alongside the counts. *** ## Push notifications in campaigns Push Notification is available as a delivery channel in the **Campaign module** alongside Email, SMS, and WhatsApp. Campaigns can target a member segment and deliver a push notification from any active push template. **Supported campaign types:** Promotional, Occasion Reward, and Reward to Members. To use push in a campaign: 1. Create a push notification template in **Engage → Communications** 2. When creating a campaign, select **Push Notification** as a delivery channel 3. Link the push template to the campaign 4. Campaign performance metrics show **Total Sent**, **Success**, and **Failed** counts for push delivery Push notifications in campaigns are delivered after the campaign cron executes — not immediately on campaign activation. ## Troubleshooting **Push notifications not reaching the member's device.** * Confirm the member has the Loyalife app installed, is logged in, and has granted notification permissions on their device. * Check the delivery log on the member's profile (**Account Info → Communications**) for the failure status. * A Failed status means the FCM token is no longer valid. This happens when the app is uninstalled or the user logs out. The notification cannot be recovered; the member must reinstall and log in. **FCM is not configured for the program.** * FCM setup is done during program onboarding. Contact your Loyalife team to verify FCM is configured and the correct Firebase project credentials are linked to your program. # Segments Source: https://help-loyalife.xoxoday.com/user-guides/engage/segments Divide your member base into targeted segments by behaviour, demographics, or spend for rules, campaigns, and communications. Segments define *who* a rule, campaign, or communication targets. Build a segment once, and Loyalife keeps it current — members enter or exit automatically as their data changes. Segments power the Rule Engine (by restricting earning rules to specific audiences), campaigns, and communications. ## Accessing segments Navigate to **Engage → Segments** in the left sidebar. Segments Dashboard listing all segments with Segment Name, Segment ID, Total Members, Linked Campaigns columns and a Create New Segment button ## Why use segments? | Benefit | What it enables | | --------------------------- | ---------------------------------------------------------------------------------- | | Targeted earning rules | Link a rule group to a segment so bonus earning only applies to a defined audience | | Campaign precision | Send promotions only to members most likely to respond | | Personalised communications | Tailor messages by member behaviour or lifecycle stage | | Segment insights | Understand how different audiences behave and compare their value | ## Segment types ### Default segments Every Loyalife program includes four pre-built segments available immediately: | Segment | Criteria | | --------------- | ------------------------------------ | | New members | Joined in the last 30 days | | At-risk members | Currently suspended or blocked | | Active buyers | Have completed at least one purchase | | Never purchased | Enrolled but have not transacted | ### Smart segments Smart segments are the custom segments you create with filter criteria. They update their membership automatically as member data changes. ## Membership behavior: Dynamic vs Frozen When creating a smart segment, you choose how membership evolves over time: | Mode | Internal value | Behavior | | ----------- | :------------: | -------------------------------------------------------------------------------------------------------------------------------------- | | **Dynamic** | 0 | Membership updates continuously — new members who meet the criteria are added automatically; members who no longer qualify are removed | | **Frozen** | 1 | Membership is a point-in-time snapshot captured at creation. No new members enter or leave, regardless of data changes | Use **Dynamic** for ongoing campaigns and rule linkages. Use **Frozen** for one-time campaigns where you want a fixed audience (e.g., "all Gold members as of campaign launch date"). ### Adding members to a frozen segment For frozen segments, you can expand the audience after creation: | Mode | Effect | | ----------- | ------------------------------------------------------- | | **Replace** | Replaces the existing member list with a new snapshot | | **Append** | Adds new qualifying members to the existing frozen list | ## Filter criteria Segment filters are organized into three categories: **Member Attributes**, **Transaction**, and **Transaction Aggregate**. *** ### Category 1 — Member Attributes #### Date-based filters | Filter | Description | | ------------------------------- | ------------------------------------------------------- | | Enrollment Date | Date the member enrolled in the program | | Activation Date | Date the account was activated | | Last Communication Sent — Email | Date the member last received an email from the program | | Last Communication Sent — SMS | Date the member last received an SMS from the program | All date filters support: **before**, **after**, **on**, **between**, **within last N days**. #### Tiers & Status filters | Filter | Options | | -------------- | ------------------------------------------------------------------------------------------------ | | Tier | Select from your configured tiers | | Last Tier | The tier the member held before their most recent tier change | | Account Status | Active (1), Suspended (2), Login Blocked (3), Canceled (4), InActive (5), Membership Blocked (6) | #### Demographic filters | Filter | Description | | ------ | --------------------------------------------------------------------- | | Age | Numeric comparison (`>`, `<`, `=`, `>=`, `<=`) based on date of birth | | Gender | Multi-select from configured gender options | #### Custom member attribute filters Any custom member attributes defined for your program appear in this group as additional filter options. Examples include occupation, region, product category preference, or any other program-specific member field configured in **Attributes**. *** ### Category 2 — Transaction Filters based on individual transaction history. #### Custom transaction attribute filters Any custom transaction attributes defined in your program appear here. Examples: merchant category, product code, channel, store ID. These filters let you build segments like "members who have ever transacted at a specific merchant category" or "members who used a specific product code." Custom transaction attributes are defined in **Rule Engine → Attributes**. Once created, they appear automatically as filter options in segments. *** ### Category 3 — Transaction Aggregate Filters based on computed values derived from transaction history across a defined time window. | Filter | Type | Description | | --------------------------------- | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------ | | Point Balance | Number | Member's current available points balance | | Total Transactions in Time Period | Int + Date range | Count of transactions within a specified date window | | Aggregate attributes | Number | Any aggregate attribute created in the Rule Engine — e.g., Monthly Spend Sum, Transaction Count (MTD/YTD), Average Transaction Value | **Example conditions using aggregate filters:** | Aggregate | Condition | Segment meaning | | --------------------------------- | ----------------- | ------------------------------------------------------- | | Monthly Spend Sum | > 20,000 | High spenders this month | | Transaction Count (MTD) | >= 5 | Members transacting at least 5x this month | | Point Balance | \< 500 | Near-zero balance members — redemption nudge candidates | | Total Transactions in Time Period | = 0, Last 90 days | Dormant members — no transactions in past 3 months | The aggregate attribute list grows as you create new aggregate attributes in the Rule Engine. Any aggregate attribute you define is automatically available here as a segment filter. *** ## Combining filters Filters within a segment are combined using **AND** logic by default — a member must meet all conditions to qualify. For OR-based logic, create separate segments and combine them in a campaign audience that targets multiple segments. ## Linking a segment to a Rule Group Segments and the Rule Engine are tightly connected. You can link a rule group to a segment in two ways: **Option 1 — From the Segment form:** Enable the **Link to Rule Group** option when creating a segment. A list of available rule groups appears. Select one (only one rule group can be linked per segment). This restricts the earning rules in that group to members in this segment only. **Option 2 — From the Segment listing:** Open the three-dot menu on any existing segment and select **Link Rule Group**. A modal appears with available rule groups for selection. **Creating a rule group from within the segment flow:** If no suitable rule group exists, click **+ Create New Rule Group** inside the segment form. Fill in the name, description, and limits. The new group is automatically linked to the segment. After saving, navigate to Rule Engine to add earning rules to the group. Only one rule group can be linked per segment at a time. Linking a different group replaces the existing linkage. ## Previewing and downloading segment members After applying filter criteria, use the **Preview** function to see a table of members who currently match before saving the segment. The preview shows: * Relation Reference * Member name From the preview, you can **Download** the matching member list as a file for offline review or sharing with other teams. ## Creating a segment When you click **Create Segment**, you choose between two creation paths: ### Smart Segment Filter-based segments that update membership automatically based on member and transaction data. Enter a clear, descriptive name (up to 100 characters). Duplicate names are blocked. The name auto-populates from the first filter if left blank. Select **Dynamic** (auto-updating) or **Frozen** (point-in-time snapshot). Alternatively, select **All Members** to create a static segment covering your entire member base. Add one or more filter conditions from the Member Attributes, Transaction, or Transaction Aggregate categories. Combine them with AND logic. Click **Preview** to see which members currently qualify. Download the list if needed. Click **Save**. The segment is created and begins reflecting real-time membership for Dynamic segments. ### Manual Segment Upload a CSV file to define a fixed member list directly. Enter a name (up to 100 characters). Upload a CSV containing the member Relation References to include. * **Append** — adds new members from the file to any existing list * **Replace** — replaces the full member list with the file contents Click **Save**. The segment is created with the uploaded member list. ## Exporting segment members From the Segments listing, open the three-dot menu on any segment and select **Export Members** to download the full member list for that segment as a CSV. ## Segment listing enhancements * **Search:** Find segments by name directly from the listing page * **Clickable names:** Segment names are hyperlinks that open the segment detail view * **Linked Campaigns column:** Shows how many active campaigns are associated with each segment ## Attribute visibility controls A dedicated **Attribute Flags** section under Feature Flags controls which attributes are visible in the segment filter: * 15 system attributes (across Member and Transaction categories) can be individually or bulk enabled/disabled * Disabling a system attribute hides it from the filter options in segment creation * Custom member and transaction attributes include an **Include in Segment Filter** checkbox, available at creation time and via Edit * Aggregate transaction attributes support the same visibility checkbox Attributes used in an existing segment can still be disabled — the segment continues to function, but the attribute will not appear as an option when creating new segments. ## Using segments in campaigns and communications When creating a campaign or communication, you select a segment as the target audience. Only members in the segment at the time of the qualifying event (for campaigns) or message send (for communications) will be included. ## Troubleshooting **Segment member count looks unexpectedly low.** * Verify that all filter conditions are correct — especially date ranges and aggregate attribute thresholds. * For Dynamic segments, membership updates continuously; count reflects current state. * For Frozen segments, count is fixed at the time of creation. * AND logic means all conditions must be satisfied simultaneously. A member inactive for 60 days AND in Gold tier AND with balance under 500 is a stricter filter than any single condition alone. **A member who should qualify is not in the segment.** * Check the Last Communication Sent filter — if set, it may be excluding members who have never received that channel type. * For Transaction Aggregate filters, confirm the aggregate attribute formula covers the correct time window (MTD, YTD, Rolling, etc.). * Verify that the member's profile data (tier, status, custom attributes) matches the segment filters. **A Last Tier filter returns unexpected members.** * Last Tier captures the tier before the most recent tier change. A member who has never changed tiers will have no Last Tier value — they will fail a Last Tier filter regardless of condition. # SMS Source: https://help-loyalife.xoxoday.com/user-guides/engage/sms Send plain-text SMS notifications via Plivo covering transactional and promotional types, India DLT compliance, and template approval. SMS reaches members directly on their mobile number. It is the highest-reach channel for programs where members may not have the app installed or regularly check email. **Provider:** Plivo (India); varies by region for other countries ## SMS types | Type | Use case | | ----------------- | ----------------------------------------------------------------------------------------------------------------- | | **Transactional** | Triggered by a specific event (points earned, OTP, tier change) — not subject to DND restrictions in most markets | | **Promotional** | Marketing content sent via campaign to a segment — subject to DND regulations and opt-out requirements | ## Character limits | | Value | Notes | | ---------------------- | --------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | | **Ideal (single SMS)** | 160 characters | Messages over 160 characters are split into multiple segments by the carrier. The member sees one message but you are billed per segment. | | **Maximum** | 1000 characters | Hard limit; content beyond 1000 characters is truncated | Variables like `{{points_earned}}` consume characters at their rendered length, not the variable name length. A balance of `1,250` costs 5 characters, not 16. Put the most important information first — what the member earned or what action they should take. Keep under 160 characters wherever possible. ## India — DLT registration required Telecom regulations in India require all commercial SMS to be registered under the **Distributed Ledger Technology (DLT)** system. This applies to both transactional and promotional SMS. ### What DLT registration means * Your organisation must be registered as a Principal Entity on a DLT platform (Airtel, Jio, Vodafone, BSNL, or TRAI's portal) * Every SMS template must be submitted for DLT approval and assigned a **Template ID** and a **Header** (Sender ID) * Loyalife's internal CS team manages template submission and approval on Plivo on your behalf — you do not need direct Plivo access ### Template approval workflow (India) ``` You define the template content in Loyalife ↓ Loyalife CS submits the template to Plivo for DLT approval ↓ DLT platform reviews and approves (assigns Template ID) ↓ CS activates the approved template in Loyalife ↓ Template goes live and fires on the configured event ``` ### Links in SMS (India) Links can be included in DLT-approved templates but Loyalife avoids them by default. SMS links open in the device browser and land on the home screen rather than the app, causing drop-off. Use links only when a specific web landing page is the primary goal and DLT approval covers the link domain. ## Configuration fields | Field | Required | Notes | | ------------ | ---------- | ------------------------------------------------------------------------------ | | Message body | Yes | Plain text only; no HTML or markdown | | Template ID | India only | Assigned by DLT after approval; not required or used for non-India deployments | | Variables | Optional | Member and transaction variables using `{{variable_name}}` syntax | ## Other countries Outside India, DLT whitelisting is not required for most markets. Templates are created directly in Loyalife and go live without external approval. The Template ID field is not used. The SMS provider for non-India regions varies by program configuration. Contact your Loyalife team to confirm which provider is active for your market. ## Previewing and testing Use **Send Test SMS** to dispatch the template to a member's registered mobile number. Variables are replaced with real data from that member's profile. ## Delivery analytics Each template's detail view shows SMS delivery metrics over selectable time windows (7 days, 30 days, 3 months, 6 months): | Metric | Description | | ---------- | ------------------------------------------- | | Total sent | Number of SMS dispatched | | Delivered | Messages confirmed delivered by the carrier | | Failed | Messages that could not be delivered | ## Troubleshooting **SMS not delivered in India.** * Confirm the Template ID matches a DLT-approved template. Unregistered templates are silently blocked by carriers — no error is returned. * Check that the Sender ID (header) in Loyalife matches the registered header on the DLT platform. * Contact your Loyalife CS team if the Template ID needs updating after a DLT re-approval. **SMS not delivered outside India.** * Confirm the member's mobile number includes the correct country code. * Verify the message body is under 1000 characters. * Check the template is Active in Loyalife. # Triggered Campaigns Source: https://help-loyalife.xoxoday.com/user-guides/engage/triggered-campaigns Set up automated campaigns that fire on member behaviour or rule conditions covering re-engagement nudges, milestones, and event offers. Triggered campaigns are automated promotions that activate when a member meets a defined condition — not on a fixed date, but in response to something they did (or didn't do). Where broadcast campaigns are pushed to a segment on a schedule, triggered campaigns respond to individual member behaviour in real time. ## How triggered campaigns differ from broadcast campaigns | | Broadcast Campaign | Triggered Campaign | | -------------- | ---------------------------------------- | ----------------------------------------------------------- | | **Activation** | Manually published on a set date | Fires automatically when a condition is met | | **Targeting** | Entire segment receives it at once | Each member receives it individually when triggered | | **Timing** | Fixed start and end dates | Ongoing — fires whenever the trigger condition is satisfied | | **Use case** | Seasonal promotions, limited-time offers | Re-engagement, milestone rewards, lifecycle nudges | ## Common trigger conditions | Trigger | Example campaign | | ----------------------------------------------- | -------------------------------------------------------------------------------------- | | Member has not transacted in N days | Re-engagement offer: "We miss you — here's 200 bonus points on your next purchase" | | Member reaches a transaction count milestone | Loyalty reward: "Congratulations on your 50th transaction — enjoy 2× points this week" | | Member's points balance drops below a threshold | Burn nudge: "Your points expire soon — redeem now" | | Member upgrades to a new tier | Welcome to tier: "Welcome to Gold — here's a 500-point welcome bonus" | | Member's birthday month begins | Birthday reward: "Happy birthday — enjoy 3× points all month" | | Member completes enrollment | Welcome series: "Welcome to the program — here are 100 bonus points to get started" | ## Campaign components | Component | Description | | ----------------- | ------------------------------------------------------------------------------------- | | Name | Internal label for the campaign | | Trigger condition | The member event or attribute state that activates the campaign | | Incentive | What the member receives when the trigger fires | | Cooldown period | Minimum time before the same member can be triggered again (prevents repeated firing) | | Communication | Optional notification sent to the member when the campaign fires | | Active window | Optional date range during which the trigger is active | ## Creating a triggered campaign The triggered campaign creation form opens. Select the member event or attribute state that should activate this campaign. You can use member attributes, aggregate attributes (e.g., transaction count, points balance), tier changes, or inactivity periods. Define what the member receives when the trigger fires — bonus points, a multiplier, cashback, or a custom reward. Set a cooldown period to prevent the same member from triggering the campaign repeatedly in a short window (e.g., once per 30 days). Attach a [Communication template](/user-guides/engage/communications) to notify the member at the moment the campaign fires. Set the campaign to Active. It will begin firing for qualifying members immediately and continue until deactivated or the active window expires. ## Troubleshooting **The triggered campaign is not firing for an expected member.** * Verify the campaign status is Active. * Confirm the member currently satisfies the trigger condition. * Check whether the member is within a cooldown period from a previous trigger. * If an active window is configured, confirm the current date falls within it. Points awarded by triggered campaigns are recorded as **Credit By Bonus** entries on the member's ledger. Filter Transactional reports by [Credit By Bonus](/user-guides/reports/report-types#credit-by-bonus) and check the Narration column to distinguish campaign-awarded points from other bonus sources. # WhatsApp Source: https://help-loyalife.xoxoday.com/user-guides/engage/whatsapp Send template-based WhatsApp Business notifications in Loyalife covering Meta-approved templates, WABA setup, and variable mapping. WhatsApp messages are sent through the **WhatsApp Business API (WABA)**. All messages must use pre-approved templates — free-form messages are not permitted by Meta. Every piece of message content must be approved by Meta before it can be sent to members. **Provider:** Configurable WABA gateway (set up during program onboarding) ## How WhatsApp templates work Unlike Email or SMS, WhatsApp does not allow you to freely compose message content at send time. You must: 1. Define the message template in Meta's WhatsApp Business Manager 2. Submit it to Meta for approval — Meta reviews for policy compliance 3. Once approved, enter the **Template ID** in Loyalife and map your `{{variables}}` to the template's placeholders 4. Loyalife sends the approved template (with variables filled in) when the trigger event fires ## Template approval states | State | Meaning | Can edit? | | ------------ | ------------------------------------ | ----------------------- | | **Pending** | Submitted to Meta; awaiting review | Yes | | **Approved** | Cleared by Meta; active and sendable | No — content is locked | | **Rejected** | Rejected by Meta for policy reasons | Yes — edit and resubmit | Once a WhatsApp template is approved by Meta, its content cannot be modified. If you need to change the wording, you must create and submit a new template for re-approval. ## Configuration fields | Field | Required | Notes | | ---------------- | ---------------- | ------------------------------------------------------------------------------- | | Template ID | Yes | The WhatsApp-approved template identifier from your WABA account | | Language code | Yes | Language of the approved template (e.g. `en`, `ar`) | | Message body | Yes | Must match the approved template content; use `{{variables}}` for dynamic parts | | Variable mapping | Where applicable | Maps Loyalife variables to each numbered placeholder in the template body | ## Notification types | Type | Use case | | ----------------- | ------------------------------------------------------------------------------------- | | **User-specific** | Event-triggered messages to an individual member (points earned, claim approved, OTP) | | **Broadcast** | Announcement to a segment (new scheme launch, campaign activation) | ## Previewing and testing Use **Send Test WhatsApp** to send the template to a specific member's registered WhatsApp number. Confirm the member's number is registered and active on WhatsApp before testing. ## Delivery analytics Each template's detail view shows WhatsApp delivery metrics over selectable time windows (7 days, 30 days, 3 months, 6 months): | Metric | Description | | ---------- | ------------------------------------------ | | Total sent | Number of messages dispatched | | Delivered | Messages confirmed delivered to the device | | Failed | Messages that could not be delivered | ## Troubleshooting **WhatsApp messages not delivered.** * Verify the Template ID matches an approved template in your WABA account. Pending or Rejected templates cannot be sent. * Confirm the language code in Loyalife matches the language of the approved template in WhatsApp Business Manager. * Check that the member's WhatsApp number is valid and has not opted out of business messages. **Template approval is taking longer than expected.** * Meta's review process typically takes 24–48 hours. Business verification status and template category (transactional vs. marketing) can affect review time. * Marketing-category templates face stricter review than utility/transactional templates. If your template is promotional, categorise it correctly in WhatsApp Business Manager. The WhatsApp Business API provider (WABA gateway) is configured during program setup and can vary per deployment. Contact your Loyalife team to confirm which gateway is active for your program and to manage template submission. # Fraud Prevention overview Source: https://help-loyalife.xoxoday.com/user-guides/fraud-prevention/overview Detect and flag unusual loyalty transactions in real time with configurable thresholds and product-level anomaly detection. The Fraud Prevention module monitors transactions against configurable thresholds and flags anything that deviates from expected behavior. It gives your team a chance to review and act on suspicious activity before points are permanently credited or redeemed. ## What it does | Capability | Description | | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------ | | **Anomaly detection** | Flags transactions that exceed configured thresholds based on points volume, transaction frequency, or product-specific limits | | **Real-time notifications** | Alerts administrators to unusual accrual and redemption activity as it happens | | **Pending review queue** | Holds flagged transactions so a human can approve or reject before points are finalized | | **Loss mitigation** | Enables corrective action before suspicious activity escalates into financial damage | ## How to enable Fraud Prevention Fraud Prevention must be activated at three levels: This foundational step is performed by the Loyalife team or your DevOps team in the environment configuration file. It cannot be done from within the Loyalife UI. Contact Loyalife support to request this activation. Once the environment is configured, navigate to **Fraud Prevention** in the left sidebar and enable the module from the available options. After the module is active, go to **Fraud Prevention → Threshold Settings** to define the detection parameters. Once saved, the system begins monitoring all transactions against those thresholds. All three levels must be active for fraud detection to function. Completing only Level 2 without Level 1 environment configuration will not enable monitoring. ## Anomaly detection Anomaly detection works by comparing incoming transaction data against the thresholds you define per product code. When a transaction exceeds a threshold, it is flagged as anomalous and sent to the **Pending Transactions** queue for manual review. ### How thresholds are structured Thresholds are configured at two levels: | Level | Scope | Example | | ------------------------- | ---------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | | **Global** | Applies to all transactions, regardless of product code | Flag any member who earns more than 10,000 points in 30 days | | **Product code-specific** | Applies only to transactions tagged with a specific product code | Flag any credit card transaction above 5,000 points, but allow travel bookings up to 20,000 | Product-code-specific thresholds override the global threshold for transactions that match that product code. Product codes must exist in the Rule Engine's Attributes Manager before they can be used in anomaly detection thresholds. If no product codes are defined, the threshold settings interface will prompt you to add product codes first via **Rule Engine → Attributes → Product Codes**. ### Monitored dimensions | Dimension | What is checked | | ------------------------------- | ---------------------------------------------------------------------- | | **Points per transaction** | A single transaction that would award more than the configured maximum | | **Cumulative points in window** | Total points earned within a rolling time window (e.g., past 7 days) | | **Redemption amount** | A single redemption that exceeds the configured limit | ### What happens when a transaction is flagged 1. The transaction is held in **Pending Transactions** — it does not post points to the member's account immediately. 2. An administrator with the Fraud Review permission receives a notification. 3. The reviewer can **approve** (allow the transaction and post points) or **reject** (discard the transaction). 4. If no action is taken within the configured timeout, the transaction follows the default resolution path (approve or reject, as configured). ## Menu navigation The Fraud Prevention section contains two menu items: | Menu item | Description | | ------------------------ | -------------------------------------------------------------------------- | | **Anomaly Detection** | Configure thresholds and view the anomaly detection settings | | **Pending Transactions** | Review and action transactions that have been flagged by anomaly detection | In the navigation menu, **Anomaly Detection** and **Fraud Prevention** are distinct items — they map to the same underlying module. Editing either menu label in your program's locale settings updates both. ## Related * [Threshold settings](/user-guides/fraud-prevention/threshold-settings) — configure detection limits for accruals and redemptions * [Pending transactions](/user-guides/fraud-prevention/pending-transactions) — review and act on flagged transactions # Pending transactions Source: https://help-loyalife.xoxoday.com/user-guides/fraud-prevention/pending-transactions Review, approve, or reject transactions flagged for review by Loyalife's Fraud Prevention module. When a transaction exceeds a configured threshold, it is held in a pending state rather than being processed automatically. The Pending Transactions screen is where your team reviews these flagged items and decides whether to approve or reject them. ## Accessing pending transactions Navigate to **Fraud Prevention → Pending Transactions**. ## What you see Each pending transaction shows: | Field | Description | | ---------------- | ------------------------------------------------- | | Transaction ID | Loyalife's internal reference for the transaction | | Member | The member associated with the transaction | | Transaction type | Accrual or redemption | | Points amount | The number of points involved | | Reason flagged | The threshold that was exceeded | | Submitted at | When the transaction was received | ## Reviewing a transaction For each flagged transaction, you can: * **View details** — see the full transaction data, including the source reference and any metadata submitted with the transaction * **View member profile** — check the member's history to assess whether the transaction looks consistent with their normal activity ## Approving a transaction If the transaction appears legitimate, click **Approve**. The transaction is processed and points are credited or debited from the member's account. ## Rejecting a transaction If the transaction appears fraudulent or erroneous, click **Reject**. The transaction is cancelled and no points are moved. The event is recorded in the audit trail. When a pending transaction is rejected after points were already provisionally credited, the cancellation generates a **Debit By Cancellation** entry on the member's ledger, netting the balance back. If an approved transaction is later reversed by an admin, it appears as a **Debit By Reversal** entry. Both are filterable in Transactional reports under [Reports & Analytics → Transaction Category](/user-guides/reports/report-types#transaction-categories). For systematic fraud patterns (e.g., a specific product code being exploited), update your [Threshold Settings](/user-guides/fraud-prevention/threshold-settings) after rejecting the offending transactions to prevent recurrence. ## Audit trail All approval and rejection actions are logged, including which administrator made the decision and when. This record is available in the [Administrative Data report](/user-guides/reports/report-types). # Threshold settings Source: https://help-loyalife.xoxoday.com/user-guides/fraud-prevention/threshold-settings Configure the point thresholds that trigger fraud alerts for suspicious accrual and redemption activity in Loyalife. Thresholds define the boundaries of normal activity. Transactions that exceed these limits are flagged for review before points are posted or redeemed. ## Accessing threshold settings 1. Select **Fraud Prevention** from the left sidebar. 2. Click **Threshold Settings** in the upper right corner. ## Accrual thresholds Set the maximum number of points a member can earn within a defined time window. **Example:** Flag any accrual where a member accumulates more than 1,000 points in a rolling 30-day window. This prevents scenarios where a configuration error, system exploit, or fraudulent transaction awards an unrealistically large point balance. ### Product code-specific thresholds You can assign different accrual thresholds to specific product codes (e.g., credit cards, loans, travel bookings). This lets you apply tighter controls to higher-risk product categories while leaving lower-risk products with a more permissive limit. To add a product code threshold: 1. Click **Add Product Code Threshold**. 2. Enter the product code. 3. Set the maximum points and the time window. ## Redemption thresholds Set a limit for redemption transactions to flag unusually large redemptions before they are fulfilled. Redemption thresholds flag transactions for review but do not automatically block the redemption. A flagged redemption will appear in [Pending Transactions](/user-guides/fraud-prevention/pending-transactions) for manual review. ## Saving your configuration After configuring all thresholds, click **Save**. The system immediately begins evaluating all incoming transactions against the new limits. Changes to thresholds apply to all future transactions. They do not retroactively re-evaluate historical transactions. # Accessing Loyalife Source: https://help-loyalife.xoxoday.com/user-guides/getting-started/accessing-loyalife Learn how to log in to Loyalife, complete two-factor authentication, and recover account access if you're locked out. ## Logging in Your organization provides a dedicated Loyalife URL. Navigate to it in your browser. Enter your username (typically your email address or an assigned username) and password. Use the visibility toggle to confirm your password before submitting. If your organization has CAPTCHA enabled, complete the 6-digit challenge. If it is disabled, this step is skipped automatically. When two-factor authentication is active, Loyalife sends a 6-digit One-Time Password to your registered email with the subject line **"Login OTP - Valid for 60 Seconds"**. Enter it before it expires. ## Two-factor authentication rules | Rule | Detail | | ----------------------- | ------------------------------------------- | | OTP validity | 60 seconds from the time it is sent | | Resend limit | Maximum 5 resend attempts per session | | Incorrect entry lockout | Session locks after 5 incorrect OTP entries | ## Inactivity-based password reset If your account has been inactive beyond the configured threshold (for example, 30 days), Loyalife requires you to reset your password on your next login before granting access. This prevents unauthorized use of dormant accounts. ## Forgot your password? Click **Forgot Password?** on the login screen. Loyalife sends a reset link to your registered email address. Follow the instructions in that email to set a new password. ## Account lockouts Accounts can be locked after multiple failed login attempts, or manually by an administrator for security purposes. If your account is locked: * Contact your Loyalife administrator to have it reactivated. * A password reset may be required before your next login attempt. Loyalife logs all login attempts, password changes, and account status changes in the audit trail. These records are available to administrators for security review. ## LDAP authentication Organizations using LDAP integrate their existing directory services for centralized authentication. If your organization uses LDAP: * Your credentials are validated against your organization's LDAP server, not Loyalife directly. * **Password reset is not available within Loyalife.** Manage your password through your organization's IT tools. * Some user management features within Loyalife are disabled for LDAP-authenticated accounts. # Dashboard Source: https://help-loyalife.xoxoday.com/user-guides/getting-started/dashboard Take a tour of the Loyalife dashboard and the key program metrics it surfaces at a glance. The Loyalife dashboard gives you a snapshot of your loyalty program's performance over the past 30 days — including accruals, redemptions, and member participation. It is the first screen you see after logging in. ## Dashboard sections ### Quick look Displays 30-day performance metrics alongside annual graphs that visualize: * **Accrual trends** — total points earned over time * **Point volumes** — aggregate value of points in circulation * **Redemption patterns** — how and when members are spending points Use the annual view to spot seasonal engagement patterns and evaluate the impact of campaigns or promotions. Dashboard Quick look panel showing 30-day accrual value, points accrued, points redeemed, and the aggregated value of accruals over time chart ### Member insights Tracks the health and activity of your member base: | Metric | What it shows | | ------------------- | ------------------------------------------- | | New members | Members who enrolled in the selected period | | Active participants | Members who transacted at least once | | Redemption activity | Members who redeemed rewards | The annual breakdown categorizes members by status: **active**, **blocked**, **suspended**, **inactive**, and **cancelled** — giving you a clear picture of program engagement over time. Dashboard Member Insights panel showing newly onboarded members, engaged members, number of redeeming members, and an engaged members over time chart ### Segments Displays your configured member segments alongside key performance data: * Segment name and member count * Average transaction value per segment * Purchase frequency This panel lets you quickly compare how different segments are engaging with your program without navigating to the Engage module. ### Tiers Shows the distribution of your member base across tiers: * Tier name and member count * Point accrual and redemption per tier * Members approaching the next tier upgrade The tier panel is especially useful for identifying members close to an upgrade, enabling timely nudge campaigns through the [Engage](/user-guides/engage/campaigns) module. Dashboard showing the Segments panel with member counts and transaction metrics per segment, and the Tiers panel below with tier member distribution Use the tier upgrade insights on the dashboard to trigger targeted campaigns that encourage members on the threshold to complete a qualifying action and move up a tier. # Loyalife Documentation Source: https://help-loyalife.xoxoday.com/user-guides/index Explore Loyalife's help center — everything you need to create, manage, and optimize your loyalty program. Loyalife is a comprehensive loyalty management platform that helps businesses build programs that drive customer engagement, retention, and growth. Members earn points through purchases and engagement activities, then redeem them across a rich marketplace of gift cards, products, travel, and more. ## Explore the platform Access Loyalife, navigate the dashboard, and understand your program's key metrics. View, search, filter, and manage the members enrolled in your loyalty program. Define the business logic that governs how members earn and accumulate points. Segment members into levels with escalating benefits based on engagement and spend. Grow your member base by rewarding existing members who bring in new ones. Target the right members with segments, campaigns, and multi-channel communications. Measure program performance across transactions, members, and communications. Manage team members, roles, and approval workflows for secure program operations. Detect and flag unusual transactions before they impact your program. ## How Loyalife works Loyalife operates on two core mechanisms: **Earn** — Members accumulate points through purchases, engagement activities, promotional offers, and tier progression milestones. **Burn** — Members redeem accumulated points through the Marketplace for gift cards, physical products, travel, utility payments, charity donations, and miles exchange. These mechanisms are governed by the [Rule Engine](/user-guides/rule-engine/overview), which lets you define exactly how, when, and how many points members earn for any action. # Platform overview Source: https://help-loyalife.xoxoday.com/user-guides/loyalty-overview See how Loyalife's full-stack platform powers points, tiers, referrals, and engagement programs for loyalty teams at scale. Loyalife lets businesses design and operate loyalty programs without writing backend logic from scratch. You configure who earns what, when, and how — through a rule engine, tier system, and engagement tools — and Loyalife handles the processing, storage, and communication. ## Who uses Loyalife Three types of users interact with the platform: | Persona | What they do | | -------------------------- | ------------------------------------------------------------------------------------------ | | **Program administrators** | Configure earning rules, tiers, campaigns, and access controls via the admin portal | | **End members** | Earn and redeem points through mobile apps, web portals, or integrated POS systems | | **Channel partners** | Retailers, distributors, or agents who earn rewards for sales activity via the partner app | ## Platform modules Enrol, search, and manage your loyalty program members. View balances, transaction history, and profile details. Define earning logic using IF/THEN conditions. Support for points, cashback, milestone rewards, and birthday bonuses. Create tier structures (Silver, Gold, Platinum) with qualifying criteria, benefits, and retention periods. Enable members to invite others with unique codes. Reward both referrer and new member on first qualifying transaction. Build member segments, run targeted campaigns, and send communications across email, SMS, and push channels. Access pre-built dashboards and create custom SQL-based reports with real-time preview and scheduled export. Manage team roles and permissions. Enforce maker-checker approvals and maintain a full audit trail. Set program-wide defaults: point naming, calculation method, decimal precision, and UI text customisation. Configure partner earning flows, manage QR codes, invoice claims, scheme banners, and gamification. Connect to Plum for voucher and gift card redemption via secure SSO integration. ## How a loyalty transaction flows When a member makes a purchase, Loyalife processes it end-to-end: 1. **Transaction received** — your system sends a transaction event to Loyalife via API or file upload. 2. **Fraud check** — if the transaction amount or pattern exceeds a configured threshold, the transaction is held in a pending state for admin review. Approved transactions continue; rejected ones are cancelled with no points movement. 3. **Rule Engine evaluation** — the engine evaluates all active earning rules against the transaction attributes (amount, MCC, date, member attributes). 4. **Points calculated** — matching rules determine how many points or what cashback percentage applies. Caps and limits are enforced. 5. **Tier check** — the member's updated balance is checked against tier thresholds. Upgrades or downgrades are applied if criteria are met. 6. **Member ledger updated** — a typed entry (e.g., Credit By Accrual) is written to the points ledger. The member's balance and statement are updated. 7. **Communication sent** — an SMS, email, or push notification can be triggered to inform the member of their earned reward. ## Key concepts **Rule groups** organise related earning rules. A rule group can be linked to a specific member segment, ensuring the right logic applies to the right audience. **Segments** define who a rule or campaign targets. Segments can be dynamic (auto-updating as members meet criteria) or frozen (point-in-time snapshot). **Tiers** are status levels members attain by accumulating qualifying points or spend. Each tier can have different earning multipliers and benefits. **Campaigns** are time-limited promotions layered on top of baseline earning rules. A campaign targets a specific segment during a defined window and awards bonus points, cashback, or multipliers — without permanently changing the underlying rule logic. Campaigns can be broadcast (manually scheduled) or triggered (fired automatically by a member event). **Channel partners** are retailers, distributors, or field agents who interact with Loyalife through a dedicated partner app rather than the admin portal. They earn rewards for sales activity — submitting invoices and warranty claims — rather than for purchases as end members do. Programs with channel partners have a separate approval workflow for claim verification. **Points ledger** records every credit and debit event on a member's account as a typed entry — for example, Credit By Accrual, Debit By Redemption, or Credit By Bonus. The ledger type identifies exactly what generated each movement, making it possible to filter, reconcile, and audit activity by source. See [Transaction categories](/user-guides/reports/report-types#transaction-categories) for the full reference. **Fraud prevention** allows programs to define point and transaction thresholds that hold suspicious activity in a pending state before points are posted. Administrators review flagged transactions and approve or reject them. Rejected transactions are cancelled without any points movement. **Maker-Checker workflow** governs sensitive admin actions — a maker submits a change and a checker must approve it before it takes effect. This applies to member status changes, manual point adjustments, rule activation, and more. **Audit trail** records every configuration change and user action with a timestamp, actor, and before/after values. Your access to modules depends on the permissions assigned to your role. Contact your program administrator if a module is not visible. # On behalf redemption Source: https://help-loyalife.xoxoday.com/user-guides/marketplace/on-behalf-redemption Let authorised agents and relationship managers redeem points on a member's behalf, with a full audit trail of every session. On Behalf Redemption lets authorised staff act as a member within the Plum marketplace to assist with redemptions — for example, when a member contacts support and cannot complete a redemption themselves, or when a relationship manager is assisting a client in person. ## How it works An agent with the On Behalf Redemption permission accesses a member's profile and launches a dedicated marketplace session scoped to that member. The agent can browse and complete redemptions using the member's points balance. Every action taken in this session is recorded as an on-behalf transaction, not a direct member transaction. ``` Agent opens member profile in Loyalife admin portal ↓ Clicks "Redeem on behalf" — available only with permission ↓ SSO session opens in Plum, scoped to the member's account ↓ Agent completes redemption using member's points ↓ Transaction recorded with "On Behalf Redemption" flag ↓ Full audit trail entry created: agent identity, member, amount, time ``` ## Who can use it This feature is intended for: | Role | Use case | | --------------------------- | -------------------------------------------------------------------------------------------------------- | | Customer service executives | Assist members who can't complete a redemption independently (e.g., elderly members, app unavailability) | | Relationship managers | In-person assisted redemptions for high-value clients | On Behalf Redemption requires an explicit permission in the user's role. It is not granted by default to any role and must be assigned intentionally. ## Enabling the permission 1. Go to **Access Control → Manage Team → Roles**. 2. Select the role to grant access to. 3. Locate the **On Behalf Redemption** permission under the Marketplace module. 4. Enable it and save. Treat this permission like a privileged access grant. Because agents can spend a member's points, restrict it to roles with accountability mechanisms — supervisor oversight, mandatory reason logging, or audit review processes. ## Performing an on-behalf redemption In **Members**, search for the member using their ID, name, phone number, or email. Click **Redeem on behalf** on the member profile. This button is only visible to users with the On Behalf Redemption permission. The system opens a Plum marketplace session authenticated as the member via SSO. The agent sees the member's balance and available catalogue. The agent selects items and completes the redemption following the standard marketplace flow. The transaction is placed against the member's account. When the agent closes the session, the SSO token expires. All actions taken in the session are logged. ## Audit trail Every on-behalf redemption is traceable: * The **Audit Trail** (Access Control → Audit Trail) records the agent's identity, the member account accessed, and a timestamp. * The transaction report includes an **On Behalf Redemption** filter to view all transactions performed on behalf of members — separate from direct member redemptions. The transaction report filter **On Behalf Redemption** is available in **Reports & Analytics → Reports → Transaction Report**. Use it for reconciliation and compliance review. ## What the member sees From the member's perspective, the redeemed item appears in their redemption history normally — there is no special flag in the member app. However, the transaction in the admin portal is tagged as on-behalf, ensuring the programme team can distinguish assisted redemptions from self-service ones. ## Troubleshooting **The "Redeem on behalf" button is not visible on the member profile.** * Confirm the current user's role includes the On Behalf Redemption permission. * Verify that the Plum marketplace integration is active for this program. **The on-behalf session launched but the member's balance is incorrect.** * Check that the member's account is active and not suspended. * Confirm there are no recent pending transactions that have not yet posted to the balance. **A transaction does not appear under the On Behalf Redemption filter.** * The filter only shows completed redemptions. If the session was abandoned before checkout, no transaction is recorded. On-behalf redemptions generate **Debit By On Behalf Redemption** entries on the member's ledger — separately tagged from self-service redemptions so agent-assisted activity is distinguishable in reports. If an on-behalf redemption is subsequently reversed, the restored points appear as a **Redemption Reversal** credit. Filter Transactional reports by [Debit By On Behalf Redemption](/user-guides/reports/report-types#debit-by-on-behalf-redemption) to isolate these entries. # Plum marketplace Source: https://help-loyalife.xoxoday.com/user-guides/marketplace/plum Connect Loyalife members to Plum's voucher and gift card catalogue for point redemption via secure SSO integration. Plum is Xoxoday's rewards marketplace — a catalogue of vouchers, gift cards, and experiences from thousands of brands. Loyalife integrates with Plum so that members can redeem their loyalty points directly against Plum's catalogue without re-entering credentials. ## How it works When a member chooses to redeem points through the Plum catalogue, Loyalife: 1. Validates the member's point balance and confirms it meets the minimum redemption threshold. 2. Creates a secure SSO session and transfers the member to Plum's catalogue in a single click — no separate Plum login required. 3. Plum uses a separate **Redemption Rate Token** to apply the correct points-to-currency conversion rate configured in your program. The member browses and selects a reward. The redemption request flows back to Loyalife, which debits the appropriate number of points from the member's account. ## Authentication architecture Loyalife uses two distinct API tokens for the Plum integration: | Token | Purpose | Scope | | ------------------------- | ---------------------------------------------------------------------------- | ----------------------------- | | **SSO Token** | Transfers the user session from Loyalife to Plum (single sign-on) | Authentication only | | **Redemption Rate Token** | API calls related to fetching and applying the redemption rate configuration | Redemption configuration only | These tokens are stored separately in environment configuration. Previously, a single shared token was used for both operations, which caused session conflicts and inconsistent authentication. The separation ensures each operation has its own security context. Both tokens are configured by the Loyalife implementation team. Program admins do not manage tokens directly — contact your Loyalife account team if a token needs to be rotated. ## Redemption rate The redemption rate defines how many loyalty points equal one unit of currency when redeeming through Plum. **Example:** If the redemption rate is set to 100 points = ₹1, a member with 5,000 points has ₹50 in redemption value on Plum. The redemption rate is configured in **Configuration → Marketplace Settings**. Changes to the rate use the Redemption Rate Token and take effect for new redemption sessions. ## Member experience Members access the Plum catalogue from the member-facing app or web portal. The flow: 1. Member taps **Redeem Points** or navigates to the rewards catalogue. 2. The app initiates an SSO handoff to Plum using the member's active session. 3. Member lands on Plum's catalogue, already authenticated, with their available redemption balance shown. 4. Member selects a voucher or gift card and confirms the redemption. 5. Points are debited from the member's Loyalife account. 6. The voucher or gift card is delivered to the member (via email or in-app). ## Minimum redemption threshold You can set a minimum number of points a member must have before Plum redemption is available to them. Configure this under **Configuration → Marketplace Settings**. ## Member status and redemption Only **Active** members can redeem through Plum. Members with Inactive, Suspended, Blocked, or Cancelled status cannot initiate a redemption session. ## Troubleshooting **Member cannot access the Plum catalogue (session error).** * Verify the SSO Token is valid and has not expired. Contact the Loyalife implementation team to rotate if needed. * Confirm the member's status is Active. **Redemption rate is applying incorrectly.** * Check the current rate in Configuration → Marketplace Settings. * Verify the Redemption Rate Token is correctly configured and not stale. **Points debited but voucher not received.** * Check Plum's order status for the transaction reference. * Redemption-related disputes between members and Plum should be raised with the Plum support team, providing the transaction reference from the member's Loyalife transaction history. Every successful Plum redemption generates a **Debit By Redemption** entry on the member's ledger. If a redemption is subsequently reversed (e.g., unfulfilled voucher), the restored points appear as a **Redemption Reversal** credit. Both entry types are filterable in Transactional reports under [Reports & Analytics → Transaction Category](/user-guides/reports/report-types#transaction-categories). # Member attributes Source: https://help-loyalife.xoxoday.com/user-guides/members/attributes Learn how global, custom, and aggregate member attributes power Loyalife's rules, segments, communications, and reports. Attributes are the data fields that describe a member. Loyalife organises them into three types, each serving a different purpose. Understanding the distinction matters because the attributes you configure here flow directly into the Rule Engine, segments, and communications — they're not just profile fields, they're the inputs to your entire loyalty logic. ## Why attributes matter | What you want to do | Attribute you need | | ----------------------------------------------------------- | ---------------------------------------------- | | Run a birthday cashback rule | Global attribute: Date of Birth | | Target high-spending members in a campaign | Aggregate attribute: Monthly Spend Sum | | Segment members by their occupation | Custom attribute: Occupation | | Award bonus points only to members of a specific gender | Global attribute: Gender | | Restrict a promotion to members with a particular card type | Custom attribute: Card Type | | Reward the 10th purchase every month | Aggregate attribute: Monthly Transaction Count | Every condition in the Rule Engine's IF clause references one of these three attribute types. Every filter in Segments does too. *** ## Global attributes Global attributes are the **standard member profile fields** built into Loyalife. They are fixed — the same nine fields are present for every member in every program and cannot be removed. | Attribute | Data type | PI protected | Notes | | ------------------ | --------- | :----------: | ------------------------------------------------------------------------------------------------- | | Relation Reference | String | — | Your program's unique member identifier (CIF, account number, etc.) | | Full Name | String | — | Member's full name | | Email | String | Yes | Masked in the UI unless the admin has PI Data Access permission | | Phone | String | Yes | Masked in the UI unless the admin has PI Data Access permission | | Address | String | Yes | Masked in the UI unless the admin has PI Data Access permission | | Gender | String | Yes | Masked in the UI unless the admin has PI Data Access permission | | Date of Birth | Date | Yes | Format: YYYY-MM-DD. Masked in the UI unless the admin has PI Data Access permission | | Status | String | — | Current account status — Active, Suspended, Login Blocked, Canceled, InActive, Membership Blocked | | Preferred Language | Selection | — | Controls the language used in communication templates sent to this member | Five fields — Email, Phone, Address, Gender, and Date of Birth — are automatically treated as personally identifiable information (PI). They are masked in the admin portal by default and require a separate **PI Data Access** permission to view. Every access is logged in the Audit Trail. **What you can do with global attributes:** * **Birthday rules** — award cashback or bonus points when the transaction date matches the member's Date of Birth (day + month comparison) * **Gender-based promotions** — restrict earning rules to male or female segments for targeted campaigns * **Language-based communications** — Loyalife automatically selects the correctly localised message template for each member based on their Preferred Language * **Status-based segmentation** — create a segment of Inactive members for re-engagement, or Suspended members for review Global attributes are populated at enrollment (via API, file upload, or partner app) and can be updated via the API or from the member's profile in the admin portal. Manage Member Attributes screen showing the Global Member Attributes table with Relation Reference, Full Name, Email, Phone, Address, Gender, Date of Birth, Status, and Preferred Language, followed by the Custom Member Attributes section *** ## Custom attributes Custom attributes are **program-specific member fields** you define for your business needs. No two programs need exactly the same member data — custom attributes let you extend the member profile with whatever is relevant to your program. **Examples by industry:** | Industry | Custom attribute examples | | ------------------ | ----------------------------------------------------------------- | | Financial services | KYC status, product type (savings/current/loan), segment band | | Retail | Preferred store, product category preference, loyalty card number | | Healthcare | Plan type, enrollment channel, specialist referral flag | | Channel partners | Dealer tier, territory, certification level | **Creating custom attributes:** Go to **Members → Attributes → Add Attribute**. For each attribute you define: Adding Custom Attribute modal with fields for Attribute Name, API/File Key, Data Type (String), and toggles for Field is mandatory, Field is unique, Hide on profile, and Include in member search and filters | Field | Description | | ------------------ | --------------------------------------------------------------------------------- | | Attribute Name | The label shown in the Rule Engine, segment filters, and member profile | | Data type | String, Numbers (integer), Decimals (float), or Date | | API & file key | The exact field name used when submitting the value via API or member upload file | | Field is unique | Whether values must be distinct across all members | | Field is mandatory | Whether a value is required for every member record | | Field is PI | Mark as personally identifiable — controls masking and export permissions | Once created, the attribute immediately appears as: * A filter option in **Engage → Segments** * A condition option in the **Rule Engine** (IF clause) * A personalisation variable in **Communication** templates **Downstream uses:** | Use case | How the custom attribute is applied | | ------------------------------------------ | ------------------------------------------------------------------------------------------------------- | | Segment by product type | Create a segment where `product_type = savings` — link it to a rule group for savings-specific bonuses | | Personalise communications | Insert `{{preferred_store}}` into an email template to show the member's nearest store in every message | | Restrict a promotion to certified partners | IF `certification_level = Gold THEN` 2x points on all transactions | | Report by territory | Filter the Transaction report by `territory` attribute to view activity by region | *** ## Aggregate attributes Aggregate attributes are **computed values derived from transaction history**. Unlike global and custom attributes (which describe who a member is), aggregate attributes describe what a member has done — and they update dynamically as transactions come in. **Built-in aggregate examples:** | Attribute | What it tracks | | --------------------------- | -------------------------------------------- | | Monthly Spend Sum (MTD) | Total transaction amount this calendar month | | Transaction Count (MTD) | Number of transactions this calendar month | | Lifetime Spend Sum | Total spend from enrollment to now | | Lifetime Transaction Count | Total transactions ever | | Quarter to Date Spend (QTD) | Total spend this calendar quarter | | Average Transaction Value | Mean spend per transaction | **Time windows available:** | Window | Resets | | --------------------- | -------------------------------------------------- | | Lifetime | Never | | Month to Date (MTD) | First of every calendar month | | Quarter to Date (QTD) | Start of each calendar quarter | | Year to Date (YTD) | January 1st | | Rolling N days | Sliding window — always the last N days from today | | Billing Cycle | Based on your program's configured billing period | **Aggregate functions:** Each aggregate attribute applies one of: `sum`, `count`, `max`, `min`, or `avg` across all qualifying transactions in the time window. **What you can do with aggregate attributes:** * **Milestone rewards** — fire a rule every time Monthly Transaction Count is a multiple of 10 (10th, 20th, 30th purchase) * **Spend tiers** — award bonus points for any month where Monthly Spend Sum exceeds ₹20,000 * **Segment dormant members** — create a segment where Lifetime Transaction Count = 0 (enrolled but never transacted) for a win-back campaign * **Tier qualification** — use Lifetime Spend Sum as the qualification metric for tier upgrades * **Velocity caps** — restrict an earning rule from firing more than N times per month by checking Monthly Transaction Count **Creating aggregate attributes:** Go to **Rule Engine → Attributes** and create a new aggregate attribute. Choose the source transaction field (e.g., Transaction Amount), the aggregate function (e.g., sum), and the time window (e.g., Month to Date). Once saved, the attribute appears in both the Rule Engine condition builder and in Segment filters — no additional configuration needed. Aggregate attributes are evaluated **at the time a transaction arrives** — the current transaction is included in the aggregate before the rule is checked. Reversals and refunds are automatically subtracted from the aggregate. *** ## Attribute visibility in the member profile All three attribute types appear in the member profile under the **Account Info** tab: | Section | Shows | | --------------- | ------------------------------------------------------------------- | | Profile fields | Global attributes (DOB, gender, status, preferred language, etc.) | | Custom fields | Custom attributes defined for your program | | Loyalty summary | Aggregate attribute values (current balance, lifetime earned, etc.) | Admins with PI Data Access permission can view masked fields (mobile number, email, DOB) after accepting the confirmation prompt. *** ## Updating attribute values | Method | Best for | | ---------------------------------- | -------------------------------------------------------------------------------------------------------- | | Admin portal — member profile edit | One-off corrections for individual members | | API — Update Member endpoint | Real-time updates from your application (e.g., when a member changes their city) | | Bulk CSV upload | Mass updates for many members at once (e.g., migrating a new custom attribute across your existing base) | An attribute's **data type cannot be changed** after it has been used in a live rule or segment. If you need to change the type, create a new attribute and migrate any rules or segments referencing the old one. # Member details Source: https://help-loyalife.xoxoday.com/user-guides/members/member-details A guide to every tab in the Loyalife member detail view covering account info, accrual history, statements, redemptions, transaction summaries, expiry schedules, communications, and referrals. The member detail view is the single pane of glass for an individual member's account. From here you can review identity information, loyalty activity, communication history, and referral activity — and take actions such as manual point adjustments or status changes. ## Opening a member profile Navigate to **Members**, then use search (relation reference, full name, email, or phone) or browse the member list. Click **Actions → View** to open the detail view. Member profile detail view showing Account Info tab with member MRF157 — Personal Info section, points summary panel with Current Balance, Lifetime Points, Points Redeemed, and Points Expired, and action buttons for Edit, Change Status, and Adjust Points ## Tab overview The member detail view has eight tabs. Each covers a distinct dimension of the member's account. | Tab | What it shows | | ------------------------------------------- | --------------------------------------------------------------------------- | | [Account Info](#account-info) | Identity, status, tier, segments, and action buttons | | [Accrual Info](#accrual-info) | Point balance breakdown and full earning transaction history | | [Member Statement](#member-statement) | Formatted statement view — credits, debits, and net movement for any period | | [Member Redemption](#member-redemption) | Every redemption event with channel, status, and reference | | [Transaction Summary](#transaction-summary) | Aggregated spend and transaction metrics (lifetime, MTD, QTD, YTD) | | [Expiry Schedule](#expiry-schedule) | Upcoming and past points expiry batches | | [Communication](#communication) | Full history of messages sent to this member across all channels | | [Referral](#referral) | Referrals made by this member and the referral that brought them in | Not all tabs may be visible for every user. Tab visibility depends on role permissions and enabled modules: * **Referral** tab is hidden if the Referrals module is not enabled in Configuration → Modules * **Communication** tab requires the Communications permission in your role * **Accrual Info**, **Member Statement**, and **Member Redemption** require the View Member Transactions permission * **Expiry Schedule** requires points expiry to be configured for the program If a tab you expect is not visible, check your role permissions under Access Control → Manage Team → Roles. *** ## Account Info The primary identity and status panel. **Member identification:** | Field | Description | | ------------------ | -------------------------------------------------------------------------- | | Relation Reference | Your program's unique member identifier (CIF number, account number, etc.) | | Full Name | First + last name | | Mobile Number | Registered phone | | Email Address | Registered email | | Gender | As recorded at enrollment | | Date of Birth | Used for birthday rules and KYC | | Status | Current account status (see below) | **Account statuses:** | Status code | Label | Meaning | | :---------: | ------------------ | ------------------------------------------------------- | | 1 | Active | Account is in good standing; member can earn and redeem | | 2 | Suspended | Temporarily restricted — cannot earn or redeem | | 3 | Login Blocked | Account exists but mobile login is blocked | | 4 | Canceled | Account has been permanently closed | | 5 | InActive | Enrolled but never activated | | 6 | Membership Blocked | Membership-level block separate from login | **Tier and segment information:** | Field | Description | | ------------ | --------------------------------------------- | | Current Tier | Tier name and icon | | Segments | All segments this member currently belongs to | **Program dates:** | Field | Description | | ------------------ | ---------------------------------------- | | Enrollment Date | When the member was added to the program | | Activation Date | When the account was first activated | | Last Activity Date | Date of the most recent transaction | **Action buttons available from this tab:** * **Edit** — update contact details or profile fields (subject to your role permissions) * **Change Status** — suspend, block, re-activate, or cancel the account (enters Maker-Checker queue if workflow is enabled) * **Manual Adjust Points** — initiate a manual point credit or debit *** ## Accrual Info Shows the member's point-earning history and a real-time balance breakdown. **Balance summary:** | Metric | Description | | ---------------------- | --------------------------------------------------------- | | Current Balance | Points available to redeem right now | | Lifetime Points Earned | Total points accrued since enrollment | | Points Redeemed | Cumulative redemptions | | Points Expired | Points that have lapsed | | Pending Points | Earned but not yet posted (held during processing window) | **Accrual transaction history:** Every individual earn and debit event is listed in reverse-chronological order. | Column | Description | | ------------------------------ | --------------------------------------------------------------------------------------------------------------------------- | | Transaction Date | When the earning event occurred | | Narration | Description of the activity — e.g., "Spend Points", "Campaign Bonus", "Expired Points" | | Transaction Type (TT) | 1 = Credit, 2 = Debit | | Loyalty Transaction Type (LTT) | The specific activity category — see [Transaction types](/user-guides/rule-engine/transaction-types) for the full reference | | Points | Points earned (positive) or debited (negative) | | Balance After | Running balance after this entry | | Rule Applied | The Rule Engine rule that matched this transaction | **Filter options:** | Filter | Options | | ---------------- | -------------------------------------------- | | Date range | Custom start and end dates | | Transaction Type | Credit (TT 1), Debit (TT 2), Reversal (TT 4) | Use this tab to verify that a specific purchase triggered the right rule and awarded the correct points. *** ## Member Statement A period-based formatted view of the member's account — equivalent to a bank statement for their points balance. **What's shown:** * Every credit and debit event in the selected period, in chronological order * Opening balance at the start of the period * Closing balance at the end of the period * Net movement (total credits minus total debits) **Filter options:** | Filter | Options | | ---------------- | -------------------------------------------- | | Date range | Custom start and end dates | | Transaction Type | Credit (TT 1), Debit (TT 2), Reversal (TT 4) | **Downloading:** Export the statement directly from this tab as CSV or PDF. Use this when a member disputes their balance or needs a formal points statement for compliance or audit purposes. Member Statement and Accrual Info both show transaction history. The difference is context: Accrual Info shows raw transaction-level detail for investigation, while Member Statement shows a formatted period view with opening/closing balances — more suitable for sharing with the member. *** ## Member Redemption Tracks every redemption event for this member — what was redeemed, when, how many points, and the outcome. **Redemption history columns:** | Column | Description | | -------------------- | -------------------------------------------------------------------- | | Redemption Date | When the redemption was processed | | Reward Name | Voucher, gift card, or reward item name | | Points Debited | Points consumed by this redemption | | Channel | Plum marketplace, in-store POS, API | | Status | Completed, Pending, Reversed | | Redemption Reference | Unique identifier for cross-referencing with Plum or partner systems | Use this tab to investigate disputed redemptions — confirm whether the debit was processed, on what date, and through which channel. *** ## Transaction Summary An aggregated view of the member's transaction activity — a quick health check on engagement without scrolling through individual entries. **Summary metrics:** | Metric | Description | | ------------------------- | ------------------------------------------------ | | Total transactions | Lifetime count of all transactions | | Total spend amount | Cumulative transaction value in program currency | | Average transaction value | Mean spend per transaction | | Last transaction date | Date of the most recent transaction | | Transactions this month | Count for the current calendar month | | Transactions this quarter | Count for the current quarter | | Transactions this year | Count for the current year | The figures shown here are the same values that feed aggregate attributes in the Rule Engine. If a rule condition checks "Monthly Transaction Count", the figure shown under "Transactions this month" is what gets evaluated. *** ## Expiry Schedule Shows upcoming and past points expiry events for this member — essential for support agents advising members on expiring balances. **Expiry schedule columns:** | Column | Description | | ------------ | ------------------------------------------------------- | | Point Batch | The batch of points scheduled to expire | | Points | Amount in this expiry batch | | Expiry Date | Scheduled expiry date | | Status | Upcoming, Expired, or Canceled (if expiry was reversed) | | Earning Date | When this batch was originally credited | Expiry is calculated from either the **Processing Date** (when points were posted to the ledger) or the **Point Availability Date** (when points became redeemable), depending on your program's Point Definition configuration. Use this tab proactively in member support conversations — if a large batch is expiring soon, advise the member to redeem before the expiry date, or flag the account for a re-engagement campaign. *** ## Communication A complete log of every message sent to this member through Loyalife's communication channels. **Communication log columns:** | Column | Description | | ------------- | ------------------------------------------------------------------------------------ | | Sent Date | When the message was dispatched | | Channel | Email, SMS, WhatsApp, Push Notification | | Template | The communication template that was used | | Trigger Event | The event that triggered the message (e.g., Points Credited, Tier Upgrade, Campaign) | | Status | Delivered, Failed, Pending | Use this tab to: * Confirm whether a member received a specific notification (e.g., tier upgrade, campaign reward) * Investigate a reported missing message — check Delivered vs. Failed status * Audit the complete communication history for compliance or dispute resolution *** ## Referral Tracks this member's referral activity — as a referrer sending others to the program, and as a referee who was brought in by someone else. **Referral summary:** | Metric | Description | | ---------------------------- | ----------------------------------------------------------------------------- | | Total referrals made | How many people this member has referred | | Successful referrals | Referrals that met the qualifying condition (enrollment or first transaction) | | Total referral reward earned | Points earned from successful referrals | | Referred by | The member who referred this person (if applicable) | **Referral history table:** | Column | Description | | ---------------- | -------------------------------------------------- | | Referred Member | Name and relation reference of the person referred | | Referral Date | When the referral was made | | Qualifying Event | On Enrollment or On First Transaction | | Status | Pending, Qualified, Rewarded | | Reward Points | Points credited to this member for the referral | The Referral tab only appears if the Referrals module is enabled in **Configuration → Modules**. If referrals are not configured for your program, this tab is hidden. *** ## Actions from the member profile ### Manual point adjustments Available from the Account Info tab, in the action panel at the top right. Select Credit (add points) or Debit (remove points). Enter the point amount and a mandatory reason. Choose the Loyalty Transaction Type (LTT) that best describes the adjustment — e.g., Bonus for a goodwill grant, Miscellaneous for a correction. If Maker-Checker is enabled for Manual Points, the request enters the approval queue. If not, the adjustment posts immediately. Manual point adjustments bypass the Rule Engine — no rules fire and no aggregate counts are updated. The adjustment does not take effect until an approver acts on it if the Maker-Checker workflow is enabled. Manual adjustments produce different ledger entries depending on direction and narration: * **Credit adjustments** → [Credit By Bonus](/user-guides/reports/report-types#credit-by-bonus) (e.g., goodwill grant, correction top-up) * **Debit adjustments** → [Debit By Bonus](/user-guides/reports/report-types#debit-by-bonus) (e.g., over-credit correction) * **Accrual reversal** → [Debit By Reversal](/user-guides/reports/report-types#debit-by-reversal) * **Redemption reversal** → [Redemption Reversal](/user-guides/reports/report-types#redemption-reversal) (restores previously debited points) * **Reversal of a debit** → [Credit By Reversal](/user-guides/reports/report-types#credit-by-reversal) All of these are visible in the member's transaction history and filterable under Transactional reports. ### Changing member status | Action | New status | Reversible? | Use case | | ---------------- | ---------------------- | :---------: | ------------------------------------------------------ | | Suspend | Suspended (2) | Yes | Temporary restriction — member cannot earn or redeem | | Block Login | Login Blocked (3) | Yes | Block mobile app access while keeping the account open | | Block Membership | Membership Blocked (6) | Yes | Membership-level restriction while preserving login | | Activate | Active (1) | — | Re-activate a suspended or blocked member | | Cancel | Canceled (4) | No | Permanently close the account | Status changes may require Maker-Checker approval depending on your program configuration. ### Accessing personal information Viewing raw personal data (mobile number, email, date of birth, address) requires a confirmation prompt. Every admin who accesses this data is logged in the Audit Trail for compliance accountability. PI Data Access is a separate role permission. If you do not have this permission, personal data fields are masked regardless of your other role rights. ### Linked cards and accounts When card and account linking is enabled in Advanced Configuration, the Account Info tab shows a **View Linked Cards & Accounts** button revealing: * Card / account numbers * Sub-relationship classification * Account status * Member relationship reference ID This button only appears if CRD linking is enabled for your program. *** ## Troubleshooting **Recent transactions are not showing in Accrual Info.** * Batch file transactions have a processing delay — the transaction date on the file and the posting date may differ. Widen the date filter to cover the full range. **Points balance does not match the Member Statement total.** * Pending points are excluded from the available balance but visible in Accrual Info as Pending entries. * Look for Reversal entries — they reduce the balance without being debited transactions. **Referral tab is not visible.** * The Referrals module is likely not enabled. Check **Configuration → Modules**. **Communication tab shows Delivered but the member reports not receiving the message.** * "Delivered" is the gateway status, not end-device confirmation. Check spam folders for email, and confirm the carrier isn't filtering automated SMS sender IDs. # Members overview Source: https://help-loyalife.xoxoday.com/user-guides/members/overview The Members module is Loyalife's central hub for managing enrolled customers covering identity, status, tier, balance, and history. Members are the end consumers who earn and redeem points in your loyalty program. Loyalife gives administrators a unified view of every member — from their profile and linked accounts to their full transaction history and current tier standing. ## What is a member? A member is any individual enrolled in the loyalty program. Membership can be created: * Via API (your application calls the Create Member API at sign-up or onboarding) * Via file upload (bulk CSV import for existing customer bases) * Via the partner app (channel partners onboard retailers or customers directly; subject to approval if the Maker-Checker workflow is enabled) Once created, a member receives a unique **Relation Reference** (the program's own member identifier — CIF number, account number, or equivalent) that never changes and is used across all queries, reports, and reconciliations. ## Accessing the Members module Select **Members** from the left sidebar. The members list shows: Manage Members screen listing enrolled members with Relation Reference, Member Name, Phone Number columns and a search bar with filter options | Column | Description | | ------------------ | ------------------------------------------------------------------- | | Relation Reference | Your program's unique member identifier (CIF, account number, etc.) | | Name | Member's full name | | Phone number | Registered contact number | | Tier | Current tier level | | Status | Account status badge | Use the search bar to find members by Relation Reference, name, phone, email, or card number. Use filters to narrow by status, tier, or registration date. ## Member identifiers Every member has a **Relation Reference** plus up to two product-linked identifiers: | Identifier | Used for | | --------------------------- | ------------------------------------------------------------------ | | **Card Number** | Credit card, debit card, or loyalty card products | | **Sub-relation Identifier** | Deposit accounts, loans, sub-accounts, or other financial products | ### Identifier rules | Rule | Detail | | ---------------- | ------------------------------------------------------------------------------------------------------------- | | Minimum required | At least one of Card Number or Sub-relation Identifier must be supplied at creation | | Zero value | `0` is acceptable in one field only — not both simultaneously | | Duplicate values | The same value can appear across different members, but not twice on the same member | | Updates | Card Number and Sub-relation Identifier **cannot be changed** after creation; all other fields can be updated | These rules apply to both API calls and file-based member imports. ## Member statuses | Status | Meaning | Loyalty API access | Redemption | | ------------- | ---------------------------------------------------------- | -------------------------------------------- | ---------- | | **Active** | Member is in good standing | Full access | Allowed | | **Inactive** | Member has not engaged for a configured period | Read-only access (balance, history, profile) | Blocked | | **Suspended** | Temporarily restricted by an admin action | Limited | Blocked | | **Blocked** | Locked after suspicious activity or repeated failed logins | Blocked | Blocked | | **Cancelled** | Removed from the program | None | Blocked | Inactive members can still query their points balance, view transaction history, and access profile details via API. Redemption is blocked until the member becomes active again. This ensures members retain visibility of their account even during inactive periods. ## What you can do From the Members module you can: * [Search, filter, and export members](/user-guides/members/search-filter-export) — find specific members or build segments for export * [View member details](/user-guides/members/member-details) — access a full profile including transaction history, linked accounts, and tier status * Perform bulk point adjustments via CSV upload * View and export linked accounts and card data ## Permissions | Action | Required permission | | ------------------- | ------------------- | | View member list | View Members | | View member details | View Members | | Edit member profile | Edit Members | | Adjust points | Adjust Points | | Export member data | Export Members | Actions such as suspending, blocking, or cancelling a member may require Maker-Checker approval depending on your program's configuration. Changes submitted without approval appear in the Approval Workflow queue until a checker acts on them. # Search, filter & export members Source: https://help-loyalife.xoxoday.com/user-guides/members/search-filter-export Find specific members using multiple identifiers, narrow results with filters, and export member data in several file formats. The Members list supports powerful search and filter capabilities to help you find specific individuals or build lists of members matching defined criteria. Export options cover everything from a simple filtered list to full activity logs. ## Searching for members Use the search bar at the top of the Members list. Member search is **configurable per deployment** — your Loyalife team can enable or disable specific search fields based on your program's needs and data privacy requirements. **Default search fields** (active for all programs unless changed): | Search field | Description | | ------------------ | ------------------------------------------------------------------- | | Relation Reference | Your program's unique member identifier (CIF, account number, etc.) | | Full Name | Full or partial name match | | Email address | Registered email | | Phone number | Registered mobile number | **Additional fields that can be enabled:** | Search field | Notes | | ------------------------ | ------------------------------------------------------------------------------------------- | | National identity number | Where KYC data is captured | | Member account number | Program-specific account number | | Custom string attributes | Any custom text attribute defined for your program — e.g., employee ID, loyalty card number | Contact your Loyalife administrator or implementation team to configure which fields are searchable for your program. Search is case-insensitive. Name and text attribute fields support partial matching — entering the first few characters returns all members whose value starts with those characters. ### Card-related data (CRD) search If your program uses card or account linking, the **CRD search** option lets you find members by their linked card or account number. Enter a card number or account identifier to retrieve the associated member profile. CRD search must be enabled in [Advanced Configuration](/user-guides/configuration/advanced-configuration) before it appears as a search option on the Members list. ## Filtering members Click the **filter icon** to open the filter panel. Combine multiple filters to build precise member lists: ### Status and enrollment filters | Filter | Options | | --------------- | --------------------------------------------------------------- | | Account status | Active, Inactive, Suspended, Blocked, Cancelled | | Tier | Select from your configured tier levels | | Enrollment date | Is between \[start date] and \[end date]; is within last N days | | Activation date | Is between \[start date] and \[end date]; is within last N days | ### Demographic filters | Filter | Options | | ------------------- | --------------------------------------------- | | Age | Range (min/max) or exact value | | Gender | Multi-select from configured gender options | | Language preference | Multi-select from configured language options | ### Custom attribute filters Any custom member attributes defined in your program appear as additional filter options. Array-type attributes support multi-select filtering. **Example combined filter:** "Gold tier members who enrolled in the last 90 days, gender Male, language English, who have never transacted." ## Exporting member data Loyalife provides four export options from the Members module. All exports are generated asynchronously and appear in **Reports & Analytics → Data Exports** for download once ready. | Export option | What it includes | | ---------------------------------- | ---------------------------------------------------------------------------------------------------- | | **Export entire table** | All members in the system, regardless of active filters | | **Export filtered table** | Only members matching your current search and filter criteria | | **Export all member activity** | Detailed activity logs — logins, transactions, and member actions for all members | | **Export linked accounts & cards** | Card and account linking details for all members (requires PI data permission and CRD to be enabled) | ### Bulk point adjustment To adjust points for multiple members at once: 1. Click **Bulk Point Adjustment** from the Members list. 2. Download the CSV template. 3. Fill in the Relation Reference for each member, adjustment amounts (positive to add, negative to deduct), and reasons. 4. Upload the completed CSV. Bulk point adjustments bypass the standard Rule Engine flow. If your program has the Maker-Checker workflow enabled, bulk adjustments may enter the approval queue before taking effect. Confirm the approval requirement with your administrator before running a bulk adjustment. ## Troubleshooting **Search returns no results even though the member exists.** * Try searching by a different identifier — if the phone number is not registered, search by Relation Reference or email. * Verify the member was created successfully — check the Logs report for any failed enrollment imports. **A member does not appear in a filter result but should match the criteria.** * Check each filter condition individually to identify which criterion is excluding them. * For enrollment date filters, ensure the date range covers the member's actual enrollment date. * For custom attribute filters, verify the member's attribute value is set correctly in their profile. **Export is taking a long time.** * Large exports are processed asynchronously. Check the Reports & Analytics → Data Exports section — the file will appear there once ready. * Very large programs (millions of members) may take several minutes for a full table export. # Mobile app for clients Source: https://help-loyalife.xoxoday.com/user-guides/mobile-app/overview Explore Loyalife's white-label channel partner mobile app covering architecture, screens, login flow, KYC, and admin configuration. Loyalife provides a white-label mobile app that client organisations deploy for their channel partners (retailers, distributors, sales agents). The app gives partners visibility into their points balance, available schemes, claim submission, and rewards redemption — directly from their phone. ## Architecture The Loyalife mobile app uses a **Server-Driven UI architecture** built on React Native. Rather than shipping separate apps for every client, a single React Native codebase renders any client's app by reading a **JSON UI schema** from the server at runtime. This means: | Benefit | What it means in practice | | ---------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | | **No app store releases for UI changes** | Updating a screen layout, adding a new section, or changing colours takes effect immediately — no app store submission required | | **One codebase, many clients** | Each client gets their own branded experience (logo, colours, screens) configured in the admin portal | | **Component registry** | All UI components (cards, lists, banners, buttons) are pre-built as a library. New screens are assembled from existing components via the JSON schema | ### How it works 1. When a partner opens the app, it fetches the current UI schema from the server for their program. 2. The **Dynamic Page Renderer** reads the schema and assembles the screen from registered components. 3. Data (balance, schemes, claims) is fetched from the Loyalife API and injected into the rendered components. 4. UI changes made in the admin portal take effect on the next app open — no reinstallation needed. ## App screens The app is structured around five primary sections accessible from the bottom navigation bar: ### Home The home screen is the primary dashboard for the partner. It displays: | Element | Description | | ------------------ | ----------------------------------------------------------------------- | | **Points wallet** | Current redeemable points balance, prominently displayed | | **Active schemes** | Cards showing ongoing earn opportunities available to the partner | | **Custom rewards** | Highlight tiles for reward catalogue features (configurable per client) | | **Notifications** | Badge count for unread alerts | The home screen layout — which sections appear, in what order, with what styling — is configurable per client via the App Config in the admin portal. ### Schemes Lists all active earning schemes the partner is eligible for, with: * Scheme name and description * Point multiplier or earn rate * Validity period * Eligible product categories Partners can filter schemes by product category or status. ### Claims The claims section handles invoice-based point earning: Partner taps **New Claim**, selects the claim type (invoice or warranty), and uploads invoice photos. The system uses OCR to extract line items from the invoice photo. The partner can review and correct the extracted data before submitting. For QR-linked claims, the partner scans the product QR code. The system validates the code and pre-fills product details. After submission, the partner can monitor the claim through the approval pipeline — Submitted → Verified → Approved/Rejected. ### Points The points history screen shows the partner's full transaction ledger: * Points earned per transaction with source details * Points redeemed with voucher or reward details * Pending points (approved but not yet posted) * Expiry schedule ### Profile Account management for the partner: * Registered name, phone, email * KYC status and documents * Support contact (configurable per client) * Terms & Conditions link (configurable per client) * Privacy Policy link (configurable per client) * Logout ## Login and KYC flow ### Login The app uses **mobile OTP authentication**: 1. Partner enters their registered mobile number. 2. An OTP is sent via SMS. 3. Partner enters the OTP to complete login. There is no username/password. The mobile number is the identity anchor for all partner accounts. ### KYC verification For programs that require identity verification, the app supports two KYC methods: | Method | How it works | | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | | **DigiLocker integration** | Partner authenticates with their DigiLocker account; Aadhaar and other government documents are pulled directly — no manual upload required | | **Manual document upload** | Partner photographs and uploads required documents (e.g., Drug License, GST certificate, PAN card) | After KYC submission: * The documents enter a review queue in the admin portal. * If approved, the partner's account is activated and they can begin earning. * If rejected, the partner is notified and can resubmit corrected documents. **Re-KYC:** For programs that require periodic KYC renewal (e.g., after regulatory changes), the app supports a Re-KYC flow where existing partners re-verify their identity without losing their account history or points balance. ## App configuration (admin) Each client's app is configured from **Configuration → Channel Partner Config → App Config** in the Loyalife admin portal. The configuration is a structured JSON document that controls the entire app experience. ### App Config structure The App Config is organized into the following top-level sections: ``` app → App-level metadata (name, version, default language) theme → Brand colours, fonts, logo URLs splash_screen → Splash screen image and duration user_type_screen → User type selection screen (shown at first login if multiple user types exist) login → Login screen configuration (OTP method, branding) home → Home screen sections, per user type side_menu → Side navigation links, per user type bottom_nav → Bottom navigation tabs, per user type ``` ### User types The app supports multiple user types — each with its own home screen layout, side menu, and bottom navigation. The two built-in user types are: | User type | Typical use | | ---------- | ----------------------------------------------------------------------------------- | | **Seller** | Channel partners, retailers, distributors — focused on scheme visibility and claims | | **User** | End consumers or members — focused on points balance, rewards, and redemption | Each user type has independent `home`, `side_menu`, and `bottom_nav` configurations. ### Home screen sections The home screen for each user type is built from **slides** (full-width banners) and **sections** (component blocks). Slides support `redirect_url` to navigate the partner to a specific screen or external URL when tapped. **Predefined sections available to add to the home screen:** | Section key | What it shows | | ---------------- | ------------------------------------------------------------ | | `Current Scheme` | Live earning scheme card with current earn rate and validity | | `Video Gallery` | Video content carousel (configured URLs per client) | | `My Tools` | Quick-access tool tiles (links to app features) | Custom sections can be added by configuring component names and data sources in the JSON. ### Bottom navigation Each user type has its own set of bottom navigation tabs. Tabs are configured with icon, label, and destination screen. **Predefined bottom nav items:** | Item | Description | | --------- | ---------------------------------------------------------------- | | Home | App home screen | | Claims | Invoice and warranty claim submission | | Scan | QR code scanner — configured as a **special button** (see below) | | Redeem | Reward catalogue and redemption | | Profile | Account settings, KYC, support | | Catalogue | Product / reward catalogue | **Special button (Scan):** The Scan item uses the `isSpecialButton: true` flag, which renders it as a prominent center button in the bottom nav bar — visually elevated above the regular tabs. This makes the QR scan action immediately prominent for channel partners. ### Side menu The side menu provides overflow navigation not included in the bottom nav. Each user type has its own side menu link list. **Predefined side menu links:** | Link | Destination | | ------- | --------------------- | | Home | App home screen | | Claims | Claim submission | | Schemes | Active scheme listing | | Redeem | Reward catalogue | | Profile | Account and settings | ### Screen routes for push notifications When configuring push notification templates in **Engage → Communications → Push**, you can specify which in-app screen opens when a partner taps the notification. The available screen routes come from your App Config's registered screens. If no route is specified, the notification opens the Home screen. ### Configurable appearance settings | Setting | Description | | -------------------------- | -------------------------------------------------------------------- | | **App name** | Displayed in the app header and splash screen | | **Primary colour** | Brand colour applied to buttons, highlights, and navigation elements | | **Logo** | Client logo for splash screen and home header | | **Support contact** | Phone number or email in Profile → Support | | **Terms & Conditions URL** | Link to the client's T\&C document | | **Privacy Policy URL** | Link to the client's Privacy Policy | ## Push notifications The app supports FCM-powered push notifications for transactional events: | Event | Default notification | | ------------------- | ---------------------------------------------------------- | | Claim approved | "Your claim has been approved! Points have been credited." | | Claim rejected | "Your claim was rejected. Tap to view the reason." | | Account approved | "Your account registration has been approved." | | Account rejected | "Your account registration was rejected." | | New scheme launched | Announcement of a new earning opportunity | Notification templates (title, body, redirect screen) are configured in **Engage → Communications → Push Notification channel**. ## Troubleshooting **Partner is not receiving OTP.** * Confirm the mobile number is registered and formatted correctly (with country code). * Check that the SMS gateway is active and the partner's carrier is not blocking automated SMS. **KYC documents are uploaded but the account is still pending.** * KYC review is a manual admin process. Documents queue in the Approval Workflow for an admin to review. * Verify an admin with the Approve Onboarding Requests permission has actioned the request. **App is not reflecting layout changes made in App Config.** * Server-Driven UI changes apply on the next app open after the config is saved. * If the partner has the app open in the background, they should close and reopen it. # Channel Partner Config Source: https://help-loyalife.xoxoday.com/user-guides/partners-promotions/channel-partner-config Configure KYC approval workflows, redemption gates, and self-registration settings for your Loyalife channel partner program. Channel Partner Config gives program administrators control over three critical gates in the partner lifecycle: how KYC documents are reviewed and approved, whether KYC verification is required before a partner can redeem points, and whether new partners can register themselves through the app. ## Overview These settings operate at the program level. Changes affect all members of the configured program. Programs that have not opted into a feature are unaffected by its configuration. ## KYC approval workflow Channel partners upload their PAN card or other KYC documents from the mobile app. Admins review and act on these submissions from the admin portal. ### Reviewing KYC submissions Go to **Partners & Promotions** > **Channel Partner Config** > **KYC**. The list shows all members who have submitted documents, with their current verification status. Select a member to view their uploaded documents and personal details. * **Approve** — sets the member's `kyc_verified` flag to true. If auto-activation is enabled (see below), inactive members are activated automatically at this point. * **Reject** — the member is notified and can resubmit corrected documents. ### KYC verified flag When a KYC submission is approved, the system sets the member's `kyc_verified` flag. This flag is what the redemption gate checks before allowing a partner to redeem their points. ## Redemption gate The redemption gate controls whether partners must be KYC-verified before they can redeem loyalty points. This is configured using the `kyc_required_for_redemption` flag, set per program. | Setting | Behaviour | | -------- | ------------------------------------------------------------------------------------------------ | | Enabled | Member must be both **Active** and **KYC-verified** to redeem; otherwise, a clear error is shown | | Disabled | Redemption is available to all active members regardless of KYC status | When redemption is blocked, partners receive one of the following error messages: * "Please complete your KYC verification to redeem" — shown when the member is active but not KYC-verified * "Member should be active to redeem" — shown when the member's account is not in an active state Programs that have not enabled `kyc_required_for_redemption` are unaffected. Partners in those programs can redeem without KYC verification. ## Auto-activation on KYC approval When the `auto_activate_on_kyc_verified` flag is enabled for a program, members who were previously inactive are automatically activated the moment their KYC submission is approved. | Setting | Behaviour | | -------- | ------------------------------------------------------------------------------------------------------------ | | Enabled | Inactive member is activated automatically upon KYC approval; no separate activation step or OTP is required | | Disabled | KYC approval sets the verified flag only; activation must be handled separately | This is useful for programs where onboarding and KYC approval happen simultaneously and a separate activation step would add unnecessary friction. ## Registration gate The registration gate controls whether new users can register themselves through the mobile app. | Setting | Value | Behaviour | | -------------------------- | ------------ | -------------------------------------------------------------------------------------------------------------------------------- | | Self-registration enabled | On (default) | Any new user can open the app and register as a channel partner | | Self-registration disabled | Off | Only members who have been pre-uploaded or pre-created in the system can log in; unknown users see a registration-disabled error | ### When to disable self-registration Disable self-registration for closed programs where access should be limited to a pre-vetted list of partners. Examples include: * Trade programs with a fixed set of distributor accounts * Pilot programs with controlled participant lists * Programs where partners are onboarded exclusively through a field sales process ## Configuration summary | Flag | Level | Default | Effect when enabled | | ------------------------------- | ------- | ------- | ------------------------------------------------------------------------------------------------------------- | | `kyc_required_for_redemption` | Program | Off | Blocks redemption for members who are not KYC-verified | | `auto_activate_on_kyc_verified` | Program | Off | Automatically activates inactive members when their KYC is approved | | `allow_self_registration` | Program | On | Allows new users to self-register via the mobile app; disable to restrict access to pre-uploaded members only | Disabling `allow_self_registration` immediately prevents new users from registering. Existing members are not affected, but any partner who has not yet created an account will be unable to do so until the setting is re-enabled. Updating Channel Partner Config settings requires the **Program Configuration** permission. # Invoice claims Source: https://help-loyalife.xoxoday.com/user-guides/partners-promotions/claims-management/invoices Review, verify, and approve invoice and warranty claims from channel partners using OCR-assisted extraction and two-level approval. Invoice claims are submissions made by channel partners to earn loyalty points on purchases they have made. Warranty submissions follow the same pipeline but register product coverage rather than awarding points. Both flow through a two-level approval process before being finalised. ## Claim types Every claim is tagged with a type badge that is visible in the list and in the detail view. | Type | Badge colour | Points awarded | Description | | -------- | --------------------------------------------- | -------------- | --------------------------------------------------------------------------------- | | Claims | Blue (`#E5F3FF` background, `#144DFF` text) | Yes | Standard invoice claim — loyalty points are credited on approval | | Warranty | Purple (`#F9EBFF` background, `#7D00CC` text) | No | Product coverage registration — no points are awarded regardless of configuration | For Warranty claims, the **Points Awarded** field is hidden in the approval modal and the system enforces a points value of zero server-side. Approving a Warranty claim never credits points. ## How a claim is submitted In the channel partner mobile app, the partner taps **New Claim**, selects the claim type (invoice or warranty), and chooses how to capture the invoice. If the partner selects **Scan Receipt**, they upload one or more invoice photos. Loyalife's OCR engine reads the image and automatically populates: * Product names and descriptions * Product codes / SKU identifiers * Quantities, unit prices, and line totals Each extracted field carries an **OCR confidence score** (0–1 scale). Scores close to 1 indicate a reliable read; scores below 0.7 flag fields that may need review. Extracted product codes and names are matched against the program's product catalogue using approximate (vector-embedding) matching. The system attaches a **match confidence score** to each line item. On the review screen, the partner sees all extracted line items and can edit any field, add missed items, or remove incorrect ones. Edited fields are flagged so admins can distinguish OCR-extracted values from manual corrections. For QR-linked claims, the partner scans the product QR code instead of uploading a photo. The system validates the code and pre-fills product details automatically. The partner submits the claim. It enters the admin approval queue with all extracted data, confidence signals, and any corrections attached. ## OCR signals in the admin view When an admin opens a claim submitted via **Scan Receipt**, the line items table shows additional signals to help prioritise review: | Signal | What it means | | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | | **OCR confidence** | Per-field score (description, product code, quantity, unit price, amount) on a 0–1 scale. Low scores highlight fields likely to be misread. | | **Match confidence** | How closely the extracted product matched the programme catalogue — high cosine similarity indicates a strong match. | | **Match method** | How the match was found: exact code, approximate name, or vector-embedding match. | | **Added by admin** | Flags any line item manually inserted by an admin rather than extracted by OCR. | | **Duplicate invoice** | If the same invoice number exists in a previous claim, the related claim IDs are listed as a warning. | OCR confidence scores reflect the original extraction snapshot. Even if a partner edited a field, the admin view shows the **original OCR reading** alongside the corrected value so you can compare what was read vs. what was changed. ### Handling low-confidence extractions When a field's OCR confidence is low (typically below 0.7): 1. Open the original invoice image from the claim detail. 2. Manually verify the field value against the source document. 3. Edit the line item if the extracted value is incorrect. 4. Enter remarks explaining any corrections before approving. Fields with low OCR confidence are visually highlighted in the review interface. Focus your manual review on flagged fields — not every line item equally. ### Duplicate invoice detection Loyalife checks whether the same invoice number has been used in a previously processed claim. If a duplicate is detected: * The admin review screen shows a warning banner listing the related claim IDs. * The claim is **not** automatically rejected — the admin must decide whether the duplicate is legitimate (e.g., a split shipment on a single invoice) or fraudulent. ### Photo upload limits | Limit | Detail | | ------------------------ | ------------------------------------------------- | | Maximum photos per claim | Configured per program (typically 1–3) | | Accepted formats | JPG, JPEG, PNG | | Recommended resolution | 1 MP or higher for reliable character recognition | Product codes must exist in the Rule Engine's Attributes Manager before they are available for OCR matching. If a product is not in the catalogue, it appears as an unmatched item and requires admin intervention. ## Filtering claims The filter bar is available on both the **Pending Actions** tab and the **All Status** tab. Claims Management — Invoices screen showing the Approval Workflow banner with 329 invoices in queue and Start Approval button, Pending Actions tab active, and claims list with Partner Name, Claim ID, Type badge, Invoice Number, Amount, and Claim Submitted On columns Claims Management — Invoices All Status tab showing the same columns with an additional Status column displaying Pending Approval and Failed status badges for each claim | Filter | Options | | -------------- | --------------------------- | | Claim Type | All Types, Claims, Warranty | | Partner Name | Free-text search | | Invoice Number | Free-text search | Filters are combinable — for example, you can filter for Warranty claims submitted by a specific partner. ## The approval workflow Invoice claims go through two levels of approval before they are finalised. ### Step 1 — Approver 1 Approver 1 is the first-level reviewer. The role assigned to this step varies by program — it could be a field manager, area coordinator, or any equivalent role (e.g., ASM, RSM). This step requires the **Approve Assigned Invoices** permission. Go to **Partners & Promotions → Claims Management → Invoices** and select a claim from the **Pending Actions** tab. Review the claim details, line items, and any attached documents submitted by the partner. For OCR claims, check confidence signals and correct any low-confidence fields. Enter remarks explaining your verification decision. Remarks are required before the claim can move forward. Attach a supporting file if needed. Accepted formats: JPG, JPEG, PNG, PDF. Maximum file size: 5 MB. Submit your verification. The claim status changes to **Pending From Others** and moves to Approver 2's queue. ### Step 2 — Approver 2 Approver 2 is the final decision-maker. View Invoice detail showing Invoice Details panel with Pending Approval status, Alerts panel (Duplicate Invoice Detection warning), Line Items table with OCR confidence signals, Partner Details with past invoices thumbnails, Reward Points section, and Timeline with action history The role varies by program — it could be a regional head, national manager, or central approver (e.g., Head Office). Claims awaiting final action appear in the **Pending Actions** tab for Approver 2. Open the claim to see the full detail view. The detail view shows invoice details, any system alerts (including duplicate warnings), line items with OCR signals, and the remarks and supporting document uploaded by Approver 1. Select one of the three available actions: * **Approve** — finalises the claim; points are credited (for Claims type) or no points are credited (for Warranty type) * **Reject** — rejects the claim; no points are credited * **Skip** — defers the claim without approving or rejecting it ## Supporting documents Approver 1 may attach a supporting document during verification. Documents must meet the following requirements: | Requirement | Detail | | ----------------- | ----------------------------------------------------------------------------------------------- | | Accepted formats | JPG, JPEG, PNG, PDF | | Maximum file size | 5 MB | | Visibility | Approver 2 can view the document in the claim detail; it is also downloadable from the timeline | ## Timeline and audit trail Every action taken on a claim is recorded in the timeline section of the claim detail view. Each timeline entry shows: * The user who performed the action * Their role * The date and time of the action * Any remarks they entered * Any supporting document they attached (with a download link) Entries are displayed in chronological order, giving you a full audit trail from submission to final decision. ## Claim statuses | Status | Meaning | | ------------------- | ------------------------------------------------------------------------- | | Submitted | Claim received from the partner, awaiting Approver 1 action | | Verified | Approver 1 has reviewed and submitted remarks | | Pending From Others | Approver 1 has completed their step; awaiting Approver 2's final decision | | Approved | Approver 2 has approved the claim; points credited (Claims type only) | | Rejected | Approver 2 has rejected the claim; no points credited | Access to invoice claims requires the **View Claims** permission. Approving requires **Approve Assigned Invoices** for Approver 1, and the corresponding approval permission for Approver 2. ## Claim alerts and settings Navigate to **Partners & Promotions → Claims Management → Settings** (gear icon in the top right) to configure program-wide claim validation rules. Claims Settings screen showing Built-in Alerts section with toggles for Unable to fetch details, Line item sum mismatch, and Duplicate invoice number checks, plus Custom Alerts section with a High value invoice rule configured to flag invoices with Amount >= 2000 **Built-in alerts** run on every invoice automatically — no configuration required: | Alert | When it fires | | ------------------------ | -------------------------------------------------------------- | | Unable to fetch details | Invoice image is missing or unreadable by OCR | | Line item sum mismatch | Sum of line items does not match the invoice total | | Duplicate invoice number | The same invoice number has been submitted in a previous claim | **Custom alerts** flag matching invoices with a warning icon in the claims list and are configurable per program (for example, flagging all invoices above a certain amount threshold for extra scrutiny). ## Troubleshooting **OCR extracted incorrect product details.** * Review the original invoice image in the claim detail. * Edit the line items manually and enter the correct values before approving. **A product is not matching in the catalogue.** * Verify the product code exists in **Rule Engine → Attributes Manager**. * If the product was recently added, allow time for the catalogue index to update. * Manually enter the correct product code in the line item editor. **OCR confidence scores are consistently low for a client's invoices.** * Partners should photograph invoices flat, in good lighting, without glare or shadows. * A minimum resolution of 1 MP significantly improves extraction reliability. # Visibility claims Source: https://help-loyalife.xoxoday.com/user-guides/partners-promotions/claims-management/visibility Review photo evidence from retailers and merchandisers to verify product or banner display compliance at their stores. Visibility claims are submissions where retailers or merchandisers upload photographs to prove they have displayed a product, shelf arrangement, or promotional banner at their physical location. Approving a visibility claim credits loyalty points that have been system-calculated based on the associated visibility asset. ## What are visibility claims When a visibility program is active, retailers and merchandisers can submit photo evidence directly from the mobile app. Visibility — Pending Actions tab showing Approval Workflow with 17 submissions in queue, and claims list with Partner Name, Claim ID, Submitted On, Merchandiser Upload (Yes/No), and Actions columns Visibility — All Status tab showing the same columns with a Status column added, displaying Approved, Pending Approval, and Pending with Other status badges for each submission The admin portal provides a structured review workflow so approvers can assess both images and partner details before making a decision. Visibility claims appear in claim reports and audit logs. You can filter any report by **Claim Type = Visibility** to isolate them. ## Reviewing a visibility claim Open a claim to see the full detail view, which is divided into the following sections. ### Approval workflow header Shows how many claims are currently in the queue and your position within it. Use this to navigate between claims without returning to the list. ### Claim details | Field | Description | | --------------------- | ----------------------------------------------------------------------------------------------------------- | | Claim ID | Unique identifier for this visibility claim | | Visibility Asset Type | The type of asset the partner was required to display (for example, shelf unit, window banner) | | Coordinates | Latitude and longitude recorded at the time of upload (read-only; captured automatically by the mobile app) | ### Image evidence Two image slots may be present, either separately or together. View Submission detail for claim #3659 showing Partner Upload panel with a shelf product photo, Merchandiser Upload panel showing Awaiting image placeholder, Partner Details section with partner name and submission timestamp, Merchandiser Details, Reward Points section, and Timeline with claim submitted entry | Slot | Uploaded by | Description | | ------------------- | ------------ | ----------------------------------------------------------------- | | Partner Upload | Retailer | Photo of the displayed product or banner taken by the store owner | | Merchandiser Upload | Merchandiser | Photo taken by the merchandiser who set up the display | Both images can coexist on the same claim. Review each image independently before making a decision. ### Partner details | Field | Description | | -------------- | -------------------------------------------------- | | Name | Partner's registered name | | Partner ID | Unique identifier | | Submitted Date | Date and time the claim was submitted | | Remarks | Any notes the partner included with the submission | | View Member | Link to the partner's full member profile | ### Merchandiser details This section is shown only when a merchandiser image is present on the claim. | Field | Description | | --------------- | ---------------------------------------- | | Name | Merchandiser's name | | Merchandiser ID | Unique identifier | | Submitted Date | Date and time of the merchandiser upload | | Remarks | Notes added by the merchandiser | ### Reward points Displays the points that will be credited if the claim is approved. This value is read-only and calculated by the system based on the visibility asset configuration. ### Timeline A full audit trail of every action taken on this claim, including timestamps and user details. See [Timeline and audit trail](#timeline-and-audit-trail) below. ## Taking action Go to **Partners & Promotions** > **Claims Management** > **Visibility** and select **Pending Actions**. You can open a claim from the list or use the **Start Approval** button in the Approval Workflow section to work through the queue in order. You can also open a claim from the row-level action menu. Examine both the Partner Upload and the Merchandiser Upload (if present). Check the coordinates, submitted date, and any remarks. Select the appropriate action: * **Approve** — opens a confirmation modal. Enter a mandatory reason (maximum 50 characters) and confirm. Points are credited to the partner immediately. This action cannot be reverted. * **Reject** — enter a mandatory reason. No points are credited. * **Exit Workflow** — closes the current claim and returns you to the queue without taking any action. Approving a visibility claim is irreversible. Points are credited immediately upon confirmation and cannot be recalled through the admin portal. Review the image evidence carefully before approving. ## Timeline and audit trail Every approval and rejection is recorded in the timeline section of the claim, showing the approver's name, action taken, reason provided, and timestamp. Use the timeline to understand the full history of a claim. ## Permissions Access to visibility claims is controlled by two permissions. | Permission | Effect | | --------------------------- | ---------------------------------------------------------------------------------- | | Approve Visibility | Approver can see and act on all visibility claims in the program | | Approve Assigned Visibility | Approver can only see and act on claims that have been explicitly assigned to them | At least one of **Approve Visibility** or **Approve Assigned Visibility** must be assigned to a user before they can access the visibility claim approval workflow. ## Reporting Visibility claims are included in the standard claims reports. To isolate them, apply the **Claim Type = Visibility** filter when running or exporting a report. # Gamification Source: https://help-loyalife.xoxoday.com/user-guides/partners-promotions/gamification Create scratch cards, spin wheels, and dice games in Loyalife to reward channel partners with vouchers and prizes. Gamification lets admins configure reward-based games that channel partners play to win vouchers. Three game types are available: Scratch Card, Spin the Wheel, and Roll a Dice. Each game has configurable rewards and win probabilities that you define at creation time. ## Overview Games appear to partners in the mobile app as interactive experiences. The reward a partner wins is determined by the probability weights you configure — the animation they see always reflects the actual result. ## Dashboard The Gamification dashboard shows a summary of activity across all games in your program. | Metric | Description | | ------------------- | ------------------------------------------------- | | Total Games | Total number of games ever created | | Active Games | Games currently set to Active status | | Total Engaged Users | Unique partners who have played at least one game | Below the summary, the games table lists each game with the following columns: | Column | Description | | --------------- | -------------------------------------------- | | Game Name | Display name shown to partners in the app | | Game Type | Scratch Card, Spin the Wheel, or Roll a Dice | | Engaged Users | Number of partners who have played this game | | Vouchers Issued | Total vouchers awarded through this game | | Status | Active or Inactive toggle | | Actions | Edit, delete, or view details | ## Creating a game Fill in the basic information for the game: | Field | Required | Description | | ----------- | -------- | ------------------------------------------------------------------------------------ | | Game Name | Yes | Display name shown to partners | | Description | No | Brief explanation of the game and its rewards | | Start Date | Yes | Date from which partners can play | | End Date | Yes | Date after which the game is no longer available; must be on or after the start date | Add one or more reward entries. Each entry represents a possible outcome when a partner plays the game. See the [Reward configuration fields](#reward-configuration) table below for the full list of fields per entry. Assign a percentage probability to each reward entry. The total across all entries must equal exactly 100%. The form shows a running total as you enter values and blocks submission if the total is not 100%. See [Win probability](#win-probability) for guidance. Select **Submit**. The game is created immediately and appears in the dashboard listing. Partners can play it from the configured start date. ## Reward configuration Each reward entry in the game has the following fields. | Field | Description | | ------------------ | ------------------------------------------------------- | | Reward Type | The type of reward (for example, Voucher) | | Voucher Category | The category the voucher belongs to | | Voucher | The specific voucher to be awarded | | Denomination Value | The monetary value of the voucher, in rupees | | Voucher Expiry | Number of days from issuance before the voucher expires | You can add multiple reward entries to a single game, each with a different voucher and probability. ## Win probability Each reward entry must be assigned a probability percentage. The system enforces the following rules: * Probabilities must be whole or decimal numbers greater than zero * The sum of all probabilities must equal exactly **100%** * The form displays a real-time running total as you enter values * Submission is blocked if the total is not 100% If you have three reward entries, a valid distribution might be 60%, 30%, and 10%. The partner's outcome is determined server-side using these weights — the game animation always matches the server result. ## Game types ### Scratch Card Partners scratch the card on their screen using a touch gesture, which progressively reveals the reward underneath. The card auto-reveals once the scratched area reaches a configurable threshold (for example, 60% of the surface). The revealed reward can be displayed as text or as an image. Partners can replay if the game allows it. ### Spin the Wheel Partners tap to spin a wheel divided into coloured segments. Each segment represents a possible reward. The wheel spins with a smooth deceleration animation and comes to rest on the winning segment. Segment labels, colours, and reward values are driven by your reward configuration. The animation always matches the server-determined result. ### Roll a Dice Partners tap to roll one or more dice. Each die rotates with a realistic animation before landing on a face. The final result shown matches the server-determined outcome. Multiple dice are supported, with the combined result used to determine the reward. ## Managing games ### Activating and deactivating Use the **Status** toggle in the games table to switch a game between Active and Inactive. | Status | Effect | | -------- | ------------------------------------------------------- | | Active | Game is visible and playable for partners in the app | | Inactive | Game is hidden from partners; no new plays are recorded | A game cannot be set to Active if its reward or probability configuration is invalid (for example, if the probability total does not equal 100%). Resolve any configuration issues before activating. ### Editing a game Select **Edit** from the Actions menu to update the game name, description, dates, rewards, or probabilities. Changes take effect immediately for partners who have not yet played. ### Deleting a game Select **Delete** from the Actions menu. A confirmation prompt will appear before the game is permanently removed. Deleting a game does not revoke vouchers already issued through it. Creating and managing games requires the **Gamification Management** permission. # Partners & Promotions overview Source: https://help-loyalife.xoxoday.com/user-guides/partners-promotions/overview Manage channel partner programs, promotional schemes, and engagement tools from Loyalife's Partners & Promotions module. Partners & Promotions is the section of the admin portal dedicated to the people and companies that distribute, sell, or promote products on behalf of your brand. Use it to generate QR-based rewards, review partner claims, configure promotional schemes, publish training content, control registration and KYC settings, and run gamified engagement campaigns. ## Modules | Module | What it does | | ----------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- | | [QR Code](/user-guides/partners-promotions/qr-code) | Generate and distribute batches of QR codes that transfer loyalty points to partners when scanned | | [Claims Management — Invoices](/user-guides/partners-promotions/claims-management/invoices) | Review, verify, and approve invoice-based and warranty claims submitted by channel partners | | [Claims Management — Visibility](/user-guides/partners-promotions/claims-management/visibility) | Review photo evidence that retailers have displayed a product or banner at their store | | [Scheme Banner](/user-guides/partners-promotions/scheme-banner) | Configure time-bound, SKU-targeted promotional schemes with terms and conditions on top of the Rule Engine | | [Video Management](/user-guides/partners-promotions/video-management) | Moderate user-uploaded videos and publish admin-created training or promotional content to partners | | [Channel Partner Config](/user-guides/partners-promotions/channel-partner-config) | Configure KYC approval workflows, redemption gates, and self-registration settings for partner programs | | [Gamification](/user-guides/partners-promotions/gamification) | Create scratch cards, spin wheels, and dice games that reward partners with vouchers | ## Permissions Every module in this section is access-controlled. Users must have the relevant role permission assigned before they can view or act on any module. Contact your administrator if a module is not visible in your sidebar. # QR Code Source: https://help-loyalife.xoxoday.com/user-guides/partners-promotions/qr-code Generate batches of scannable QR codes that instantly transfer loyalty points to channel partners upon redemption. The QR Code module lets admins create batches of unique QR codes, each encoding an encrypted payload that carries a point value. When a channel partner scans a code, they are redirected to a form where they submit their details and receive the configured points. ## Overview Each QR code encodes a URL in the format `baseURL?code=encrypted_code`. The encrypted payload contains the parameters you define at batch creation time — for example, `points: 20`. Codes are single-use, expiry-checked, and tamper-resistant. ## Generating a QR Code batch Generate QR Codes form showing Parameters section with key-value fields, Number of Codes input, Code Prefix field, Expiry Date picker, Base Redirect URL field, and a QR Code Preview panel on the right displaying a sample generated code Go to **Partners & Promotions** > **QR Code** and select **Create Batch**. Add one or more custom key-value parameters that will be encoded into every QR code in the batch. For example, set `points` to `20` to award 20 points per scan. Enter the number of codes to generate (maximum 100,000 per batch). Optionally add a prefix string that will appear at the start of every code identifier, which is useful for sorting and reporting. Choose the date after which codes in this batch will no longer be redeemable. Enter the base redirect URL — this is the landing page partners are sent to after scanning. The preview panel shows a sample QR code image, the constructed redirect URL, and the attached parameters. Review everything, then select **Submit** to generate the batch. Once submitted, the batch is created immediately and codes are available to download. ## Downloading codes After a batch is created, you can: * Download individual QR code images * Download all codes as a ZIP archive * Export a CSV report containing each code, its redirect URL, and its current status ## Managing batches Navigate to the **Batch Management** tab to see all batches across your program. QR Code Summary screen showing Total Batches, Total QR Codes, Used QR Codes, and Active QR Codes summary cards at the top, followed by the QR Code Batches list with Batch ID, Creation Date, Expiry Date, Total Codes, Used Codes, Active Codes, and Actions columns ### Summary metrics | Metric | Description | | --------------- | --------------------------------------------------- | | Total Batches | Number of batches ever created | | Total QR Codes | Sum of codes across all batches | | Used QR Codes | Codes that have been scanned and redeemed | | Active QR Codes | Codes that are enabled and within their expiry date | ### Batch list fields | Field | Description | | ------------- | ---------------------------------------------------- | | Batch ID | Unique identifier for the batch | | Creation Date | Date and time the batch was generated | | Expiry Date | Date after which codes in the batch are invalid | | Total Codes | Number of codes in the batch | | Used Codes | Codes redeemed so far | | Active Codes | Codes that are currently enabled | | Actions | View details, disable all codes, or enable all codes | ## Batch detail view Opening a batch shows its metadata (parameters, expiry, base URL) and a list of every code in the batch. QR Code Batch Detail view showing Batch Information panel (parameters, expiry date, redirect URL), Sequence Details section, Activation Details, and a paginated table of individual codes with their status (active, used, or disabled) and redemption timestamps From this view you can: * View the status of each individual code (active, used, or disabled) * Enable or disable individual codes * Track whether each code has been redeemed and, if so, when ## How partners redeem a QR code 1. The partner scans the QR code using their mobile device. 2. They are redirected to the configured base URL (the redemption landing page). 3. They fill in the required information on the form. 4. Points are transferred to their account upon successful submission. ## Security notes | Property | Detail | | ------------------ | ------------------------------------------------------------------------------- | | Encryption | Each code payload is encrypted — the raw parameters are not visible in the URL | | Tamper resistance | Altering the encrypted string in the URL invalidates the code | | Expiry enforcement | The system checks the batch expiry date server-side on every redemption attempt | | Usage tracking | Each code can only be redeemed once; subsequent attempts are rejected | Generating and managing QR Code batches requires the **QR Code Management** permission. # Scheme Banner Source: https://help-loyalife.xoxoday.com/user-guides/partners-promotions/scheme-banner Configure time-bound, SKU-targeted promotional schemes with custom terms and conditions on top of Loyalife's Rule Engine. Scheme Banners extend the Rule Engine with three context-sensitive controls: a validity period, an eligible SKU filter, and a terms and conditions field. Together, these let you run focused loyalty campaigns — for example, awarding extra points on a specific product range during a promotional window — without modifying the underlying rule logic. ## Overview A scheme banner does not replace a rule; it wraps it. When a scheme banner is configured on a rule, the rule only fires when all three conditions are met: the transaction occurs within the validity window, the transaction involves an eligible SKU, and the partner meets any criteria specified in the terms. Scheme Banner — Manage templates list showing Active/Inactive toggles, Scheme Name, Description, Start Date, End Date columns and a Create Scheme Banner button in the upper right ## Configuring a scheme banner Go to **Partners & Promotions** > **Scheme Banner**. Select an existing scheme to edit or create a new one. Enter a **Start Date** and an **End Date** for the promotion. Points accrue only on transactions that occur within this window (inclusive of both dates). Add the SKU codes or product categories that qualify for this scheme. You can enter SKUs individually, select from the product catalog, or upload a list in bulk. Only transactions that include at least one eligible SKU will trigger the reward. Enter the policy text for this scheme in the **Terms & Conditions** field. This is free text and is displayed to partners in the mobile app alongside the scheme details. Save the scheme banner. It becomes active at the configured start date without any further manual steps. View Scheme Banner modal showing Scheme Details panel with banner image upload, Scheme Name field, Scheme Description text area, Priority selector, Start Date and End Date inputs, and a live Scheme Preview panel on the right displaying the banner card as partners see it in the mobile app ## Validity period | Setting | Description | | ---------------------- | -------------------------------------------------------------------------------------- | | Start Date | The first date on which the scheme is active and points can be earned | | End Date | The last date on which the scheme is active | | Behaviour after expiry | The rule auto-deactivates when the end date passes; no manual intervention is required | Common use cases for validity periods: * Quarter-based distributor boosts (for example, July 1 to September 30) * Seasonal or festival promotions * Alignment with fiscal or promotional calendars If you need to edit the start date after a scheme has already become active, contact your program administrator. Changing a start date retroactively may affect points already earned under the scheme. ## Eligible SKUs | Setting | Description | | ------------------ | ------------------------------------------------------------- | | SKU Codes | Individual product identifiers that qualify for the reward | | Product Categories | Broader groupings — all SKUs within the category are eligible | | Bulk Upload | Upload a file containing multiple SKU codes at once | | Catalog Selection | Pick eligible products directly from the product catalog | Only transactions that include at least one eligible SKU trigger the rule. Transactions that contain only non-eligible SKUs do not earn points for this scheme, even if the partner and dates are valid. Common use cases for SKU filters: * Driving sell-through on newer or overstocked products * Focusing rewards on premium or high-margin items * Applying different reward rates per partner tier by creating separate schemes with different SKU lists ## Terms and conditions The terms and conditions field accepts free text. Use it to communicate: * Point reversal policy if a purchase is returned * Geographic eligibility restrictions * Non-combinability with other schemes or promotions * Regional legal requirements or disclaimers The text entered here is displayed to partners in the mobile app when they view the scheme details. ## Example campaign configuration The following is an example of a complete scheme banner configuration. | Setting | Value | | ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------- | | Scheme Name | August Premium Push | | Start Date | August 1 | | End Date | August 31 | | Eligible SKUs | SKU#12345, SKU#12346 | | Rule | Earn 15 points per unit sold | | Partner Tier Filter (on Rule Engine) | Tier A only | | Terms & Conditions | Points will be reversed if the invoiced product is returned within 30 days. This scheme cannot be combined with any other active promotion. | Result: a Tier A channel partner who sells one unit of SKU#12345 on August 15 earns 15 points. The same partner selling a non-eligible SKU on the same date earns nothing under this scheme (other rules may still apply). Scheme Banner configuration requires the **Manage Scheme Banners** permission. # Video Management Source: https://help-loyalife.xoxoday.com/user-guides/partners-promotions/video-management Moderate user-uploaded videos and publish training or promotional content to your channel partners in Loyalife. Video Management gives admins control over the video library available to channel partners. You can review and moderate videos submitted by users, publish your own training or promotional content, and control what is visible at any time using status toggles. ## Overview The video library serves two types of content: * **User-uploaded videos** — submitted by partners or field teams and requiring admin review before they become visible * **Admin-uploaded videos** — training materials, product guides, or promotional content published directly by the admin team ## The video library The main video list shows all videos in the program. Each entry displays: | Field | Description | | --------- | --------------------------------------------------------- | | Thumbnail | Preview image for the video | | Title | Name of the video | | Uploader | The user or admin who added the video | | Date | Upload date | | Duration | Length of the video | | Status | Current visibility status (see status labels below) | | Actions | Approve, reject, enable, disable, delete, or view details | Use the search bar to find videos by title, uploader name, or date. Use the status filter to narrow the list to a specific state. ## Status labels | Status | Meaning | | -------- | -------------------------------------------------------------------------------------------- | | Pending | User-uploaded video awaiting admin review; not visible to partners | | Approved | Video has been reviewed and is visible to partners (if also enabled) | | Disabled | Video exists in the library but has been hidden from partners; can be re-enabled at any time | | Rejected | Video was reviewed and declined; not visible to partners | ## Approving or rejecting user uploads User-uploaded videos appear in the library with a **Pending** status. Review them before they become visible to the wider partner base. Use the status filter to show only **Pending** videos, or locate the video directly in the list. Open the video detail view to watch the content and check the uploader information. * Select **Approve** to make the video visible to partners. The status changes to **Approved**. * Select **Reject** to decline the video. The status changes to **Rejected** and the video is no longer surfaced to partners. ## Toggling visibility For videos that are already approved, use the enable/disable toggle to control their visibility without permanently removing them. * **Disable** — sets the status to **Disabled** and hides the video from partners immediately. The video remains in the library and can be re-enabled. * **Enable** — restores visibility for a previously disabled video. This is useful for temporarily pulling content during a campaign change or product update. ## Uploading a new video Select **Upload Video** from the top of the video library. Choose the video file from your local machine. Fill in the following fields: | Field | Required | Description | | ----------------- | -------- | --------------------------------------------------------------------------- | | Title | Yes | Display name shown to partners | | Description | No | Summary of the video's content | | Tags | No | Keywords for search and categorisation | | Thumbnail | No | Custom preview image; one is generated automatically if not provided | | Visibility Status | Yes | Choose whether the video is active (visible) or inactive (hidden) on upload | Select **Upload**. The video appears in the library immediately with the visibility status you configured. ## Deleting a video To permanently remove a video from the library, select **Delete** from the video's action menu. A confirmation modal will appear before deletion is processed. Deletion is permanent. The video file, metadata, and thumbnail are removed and cannot be recovered. Use the **Disable** toggle if you want to hide a video temporarily rather than remove it entirely. ## Pagination The video library paginates automatically when the number of videos is large. Use the page controls at the bottom of the list to navigate between pages, or narrow the list using the search and filter options. Managing videos requires the **Video Management** permission. Users without this permission cannot view or interact with the video library. # Referrals overview Source: https://help-loyalife.xoxoday.com/user-guides/referrals/overview See how Loyalife's referral program turns your satisfied members into brand advocates by rewarding referrers and new members for invites. The Referrals module enables a structured member acquisition program. Each enrolled member receives a unique referral code. When they share that code and a new person joins and completes a qualifying action, both the referrer and the new member earn points. Loyalife handles the code generation, tracking, reward distribution, and performance reporting automatically. ## Why use referrals? Referral programs drive organic, trust-based growth. A person who joins because a friend recommended the program is typically more engaged than someone acquired through a paid channel — they were motivated by a trusted recommendation, not an advertisement. **What Loyalife's referral program offers:** * Unique codes automatically assigned to every enrolled member * Flexible reward triggers (on sign-up or on first transaction) * Configurable point amounts for both the referrer and the new member * Caps on how many referrals a single member can earn rewards for * Anti-fraud controls — no self-referrals, no double-rewarding * A dedicated [Performance Dashboard](/user-guides/referrals/performance-dashboard) for tracking results ## How a referral works — end-to-end ### From the member's perspective (mobile app) Members access the **Refer & Earn** screen from their profile or home screen. The screen shows: * A value proposition banner (e.g., "Invite a friend and earn 200 points!") * The member's **unique referral code** * A **Copy Code** button that copies the code to the clipboard with a confirmation toast * A **Share Invite** button that opens the device's native share sheet * An expandable **How It Works** section for education * A **Referral History** section showing past referrals and points earned ### Sharing the referral code When the member taps **Share Invite**, the native share sheet opens with a pre-filled message containing the referral link (deep link) and embedded code. The member selects their channel — WhatsApp, SMS, email, or any social app — and sends it. **Pre-filled share message example:** > "Hey! Join \[Program Name] using my code **GYREJHBDF67895R** and earn 200 points on your first transaction. Download the app here: \[app link]" The member can also copy the code manually and paste it anywhere. ### The referred friend's journey The friend taps the link. If the app is not installed, they are redirected to the App Store or Play Store. If installed, the app opens directly. On the sign-up screen, the referral code is either auto-applied from the deep link or available for manual entry. The system validates the code — invalid codes show an error; valid codes proceed. Depending on your program's reward trigger setting, the reward fires on sign-up activation **or** on the friend's first qualifying transaction. When the trigger condition is met: * The **referrer** receives their configured point reward * The **new member** receives their welcome bonus points (if configured) Both receive a notification. The referral appears in the referrer's Referral History. ## Fraud controls Loyalife enforces the following rules to prevent referral abuse: | Rule | Behavior | | ---------------------- | -------------------------------------------------------------------------------------- | | No self-referrals | A member cannot use their own referral code | | No duplicate referrals | The same person cannot be referred twice | | Rewards granted once | Each referred friend can trigger rewards for the referrer only once | | Referral cap | A configurable maximum number of qualifying referrals per member per month or lifetime | ## AppsFlyer OneLink integration Loyalife supports deep link generation through AppsFlyer OneLink. When enabled, referral links are OneLink URLs that: * Redirect to the correct app store based on the device (iOS or Android) * Open the app directly with the referral context if already installed * Attribute the install correctly to the referring member for analytics This integration is configured during program setup. Contact your Loyalife implementation team to enable it. ## Referral history and pagination The referral history section in the member app shows all successful referrals with: * The referred friend's name * Date of the referral * Points earned History is paginated when a member has accumulated a large number of referrals, so the list loads quickly regardless of volume. ## Getting started * [Referral setup](/user-guides/referrals/setup) — enable the program, configure codes, and set reward conditions * [Performance dashboard](/user-guides/referrals/performance-dashboard) — track acquisition metrics and top referrers Referral reward points are posted as **Credit By Bonus** entries on the referrer's ledger. To report on referral-driven point awards, filter Transactional reports by [Credit By Bonus](/user-guides/reports/report-types#credit-by-bonus) and check the Narration column for the referral source. # Referral performance dashboard Source: https://help-loyalife.xoxoday.com/user-guides/referrals/performance-dashboard Track your referral program ROI in Loyalife by acquisition breakdown, spend comparison, top referrers, and enrollment trend data. The Referral Performance Dashboard gives you a real-time view of how your referral program is driving member acquisition and what the quality of referred members looks like compared to members who joined through other channels. ## Accessing the dashboard Navigate to **Referral → Performance** in the left sidebar. Referral Performance Dashboard showing Member Acquisition Breakdown pie chart with referred vs non-referred split, Total Members Referred and Total Bonus Points Issued counters, and the 6-month enrollment trend chart ## Summary metrics The top of the dashboard shows two key program-level counters: | Metric | What it tracks | | ----------------------------- | -------------------------------------------------------------------------------------------- | | **Total members referred** | Count of all members who enrolled using a valid referral code since the program launched | | **Total bonus points issued** | Combined points distributed to both referrers and new members across all completed referrals | ## Visualisations ### Member acquisition breakdown A pie chart showing the split between: * Members who joined through a referral code * Members who enrolled through other channels (organic, direct, marketing) Use this to quantify what share of your total member growth is attributable to the referral program. A growing referral share indicates increasing word-of-mouth momentum. ### 6-month enrollment trend A line chart tracking monthly enrollment for both: * Referred members (enrolled using a referral code) * Non-referred members (other acquisition channels) This month-by-month view reveals whether referral-driven acquisition is growing, plateauing, or declining — and whether it moves in sync with general enrollment trends or independently. ### Spend comparison Compares the behaviour of referred vs. non-referred members across two dimensions, calculated using the previous three months of activity: | Metric | Why it matters | | --------------------- | ---------------------------------------------------------------------------- | | Average monthly spend | Higher spend by referred members indicates better-quality acquisition | | Transaction frequency | More frequent transactions from referred members indicates higher engagement | This is the most important metric for evaluating referral program ROI. If referred members spend significantly more on average, increasing your referrer reward to accelerate acquisition will have a positive return. If there is no spend difference, the issue may be in your onboarding flow for new members rather than in the referral incentive itself. ### Top referrers table A ranked table of your most successful referrers: Referral dashboard lower section showing Top Referrers table with Relation Reference, Name, Total Referrals, Total Bonus Points Earned columns, and Recently Referred Members list below it | Column | Description | | ------------------------- | ---------------------------------------------------------------------- | | Relation Reference | The referrer's unique program identifier | | Name | Referrer's name | | Total referrals | Number of successful (reward-triggering) referrals they have generated | | Total bonus points earned | Cumulative points they have received for referrals | | Link | Opens their full member profile | Use this table to identify your most valuable program advocates. Consider giving top referrers additional recognition or incentives to maintain their activity. ### Recent referrals list Displays the 10 most recently acquired referred members with enrollment date and referring member ID. The full list is paginated and can be downloaded for further analysis. If referred members spend significantly more than non-referred members, increase your referrer reward to accelerate acquisition. If spending is similar, focus on improving the new member onboarding experience — the referral is working, but the welcome journey may not be converting engagement. ## Referral history (member level) In addition to the program-level dashboard, each member's individual referral history is accessible from their member profile. The history shows: * Which friends they successfully referred * The date of each referral * Points earned per referral History is paginated for members with a large number of referrals, ensuring fast load times regardless of volume. ## Troubleshooting **Dashboard metrics are not updating.** * The dashboard refreshes in real time for new referral events. If recent referrals are not appearing, check that the reward trigger condition (activation or first transaction) has been met for those referrals. **A successful referral does not appear in the top referrers table.** * Top referrers are ranked by completed (reward-triggered) referrals, not by referral code shares. Verify that the referred member completed the required trigger action. * Check the referral cap settings — if a member has hit their monthly or lifetime cap, additional referrals may not have triggered rewards. # Referral setup Source: https://help-loyalife.xoxoday.com/user-guides/referrals/setup Enable the referral program, configure code generation, define reward triggers, and set point allocations and caps. Setting up the referral program takes five steps: enable the module, verify the auto-created attributes, configure code generation, define when rewards are issued, and set point amounts and caps. ## Step 1: Enable the referral program Navigate to **Referral** in the left sidebar and click **Enable Referral Program**. You will be prompted to confirm before the module is activated. ## Step 2: Auto-created member attributes When you enable referrals, Loyalife automatically creates two member attributes. These appear on every member profile and are available in reports and rule conditions: | Attribute | Purpose | | ----------------- | ------------------------------------------------------------------------- | | **Referral Code** | A unique code assigned to each member — shared with others to invite them | | **Referred By** | Records which member's referral code was used when this member enrolled | These attributes are system-managed. You cannot manually edit their values through the admin portal, though they can be set via API during bulk member imports. ## Step 3: Configure code generation Choose how referral codes are generated for your member base. ### Auto-generate (recommended) Loyalife generates an 8-character uppercase alphanumeric code for each member (e.g., `X3FJ92B7`). Codes are: * Unique across all members * Immutable — cannot be changed after generation * Automatically assigned to new members on enrollment (when **Auto-generate for new enrollments** is enabled) **Bulk generation:** Use the **Bulk Generate** option to create codes for all existing members who do not yet have one. This is typically a one-time action at program launch. ### External code management If your platform manages referral codes independently, disable Loyalife's code generation. Supply custom codes via API or file upload instead. The `Referral Code` attribute is available as a field in the member import file. Referral Code Setup screen showing Automatic mode selected, Auto-generate for New Enrollments toggle enabled, Bulk Generate button, and a preview table of sample referral codes assigned to members ## Step 4: Configure the deep link (AppsFlyer OneLink) If your mobile app uses **AppsFlyer OneLink** for deep linking, configure the OneLink template URL in the referral settings. This enables: * Device-aware redirects (iOS App Store vs. Google Play Store) * Direct app open with referral context if the app is already installed * Correct attribution of installs to the referring member Contact your Loyalife implementation team to connect AppsFlyer OneLink to your referral program. ## Step 5: Set the reward trigger Define when rewards are distributed to both the referrer and the new member: | Trigger | When rewards are issued | | --------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | | **Activation** | The referrer earns points as soon as the referred member activates their account — no transaction required | | **First transaction** | Rewards are held until the referred member completes their first qualifying transaction — both parties receive their reward at the same time | "First transaction" is the more common trigger because it ensures the referred member is genuinely engaged before rewards are paid out, reducing the risk of fraudulent or low-quality acquisitions. Referral Reward Setup tab showing On Activation and On First Transaction trigger options, member lifecycle flow diagram illustrating the referral journey from code share to reward credit, and the Points Allocation section with Referrer Reward and Referee Reward fields ## Step 6: Define point allocations Set the reward amounts for each party: | Field | Required | Description | | --------------- | -------- | --------------------------------------------------------- | | Referrer reward | Yes | Points awarded to the member who shared the code | | Referee reward | Optional | Welcome bonus points awarded to the newly referred member | Setting a referee reward (welcome bonus) increases the new member's motivation to use the referral code and complete the trigger action. ## Step 7: Set a referral cap Limit how many successful referrals a single member can earn rewards for. This prevents a small group of power users from dominating your referral budget: | Setting | Options | | ------------- | ------------------------------------------------------------ | | Cap timeframe | Monthly or Lifetime | | Cap limit | Maximum number of qualifying referrals per member per period | Once a member reaches their cap, any additional referrals they generate will not award them points (though the new member's welcome bonus, if configured, is still issued). ## Fraud controls These rules are enforced automatically and cannot be disabled: | Rule | Behavior | | -------------------------- | ----------------------------------------------------------- | | No self-referrals | A member cannot use their own referral code | | No double referrals | The same person cannot be referred by two different members | | One-time reward per friend | Each referred friend triggers a referrer reward only once | ## Audit trail All changes to referral configuration — point amounts, triggers, cap settings, and code generation settings — are logged in the Audit Trail with a timestamp and actor. This ensures accountability when multiple managers have access to the referral module. # Custom reports Source: https://help-loyalife.xoxoday.com/user-guides/reports/custom-reports Build SQL-based custom reports in Loyalife with real-time preview, scheduled generation, filtering, and controlled sharing. Custom Reports let you query your loyalty program data directly using SQL. Unlike standard pre-built reports, custom reports give you full control over which fields to include, how data is filtered, and which date ranges to analyse. You can preview results in real time, schedule recurring exports, and generate one-time reports on demand. ## What custom reports are for Standard Loyalife reports (transaction, member, communication) cover the most common use cases. Custom reports fill the gaps when you need: * Metrics that combine data from multiple standard report categories * Non-standard aggregations (e.g., average basket size by tier by month) * Ad-hoc analysis for a specific date window without changing your recurring schedule * Customised exports for stakeholder or compliance reporting ## Accessing custom reports Navigate to **Reports & Analytics → Data Exports → Custom Reports** tab. ## Creating a custom report From the Custom Reports tab, click **Create Report**. Give the report a clear name and an optional description. The description is visible in the Report Settings panel and helps other users understand the report's purpose. Enter your SQL query in the query editor. The query can reference any table available in your Loyalife data schema. Use named parameters — `:start_date` and `:end_date` — if you want the report to support custom date range generation. **Example parameter usage:** ```sql theme={null} SELECT member_id, SUM(points_earned) AS total_earned FROM transactions WHERE transaction_date BETWEEN :start_date AND :end_date GROUP BY member_id ``` Choose how often the report runs automatically: | Schedule | Frequency | | ----------- | ------------------------------------------------------------------------- | | Daily | Runs every day | | Weekly | Runs once per week | | Monthly | Runs once per month | | Manual only | No automatic generation — report runs only when you explicitly trigger it | Use **Manage Report Sharing** to specify which users and roles can view or download this report. Sharing rules control who sees the report in their Custom Reports list. Save the report. It appears in the Custom Reports listing and will begin generating on schedule. Only Super Admins can create and edit custom reports. Any user with access to the report (as defined by the sharing settings) can view, preview, and generate on-demand exports. ## Real-time preview You can preview the results of a custom report directly inside the dashboard without exporting a file. Click the report to open its detail view, then use the **Preview** panel to see the current data result set displayed as an interactive table. This eliminates the need to export a file just to check whether a query is returning the right data. Previous behaviour required downloading a CSV for every verification step. ### Report Settings panel Every custom report has a **Report Settings** button that reveals: | Setting | Description | | -------------------- | ------------------------------------------------------ | | Description | The report's purpose and data coverage | | Period of generation | The scheduled frequency | | SQL Query | The underlying query, readable for review or debugging | ### Manage Report Sharing panel The **Manage Report Sharing** button shows: | Setting | Description | | ------------------------- | ------------------------------------------ | | Reports shared with | Specific users who can access this report | | Reports shared with roles | Roles whose members can access this report | ## Search and filter on report data Custom report outputs now include **AG Grid**-powered real-time search and filtering directly on the loaded CSV data: ### Filtering | Feature | Detail | | ------------------------ | -------------------------------------------------------------------------------------------------------------- | | **Global search** | Searches across all columns simultaneously | | **Column-level filters** | Applied on top of global search with AND logic; multi-column filtering supported | | **Filter types** | Auto-assigned: text filter for string columns, number filter for numeric columns, date filter for date columns | | **Filter reset** | Clear all active filters with one click | ### Sorting and pagination * Sorting available on string, numeric, and date columns * Pagination options: **50**, **100**, **500**, or **1,000** rows per page ### Filtered export Click **Export CSV** to download only the rows matching your current filter state — not the full report. This makes it easy to share a filtered slice of data without modifying the underlying query. Column headers are auto-detected from the CSV file — no configuration is needed. Filters are client-side only and do not modify the stored report or its schedule. Search and filter are not available on the Report Data tab — only on the report output view after opening a generated file. ### View links in reports Custom reports include clickable **View Segment** and **View Campaign** links in applicable report types. These links navigate directly to the relevant Segment or Campaign detail page. If your session has expired, clicking the link redirects to the login page. ## On-demand generation (custom date range) Any custom report that uses `:start_date` and `:end_date` parameters in its SQL query can be generated for a specific date window on demand, without changing the recurring schedule. Navigate to the custom report's detail view. The **Generate** button opens a popup requiring: | Field | Required | | ---------- | -------- | | Start Date | Yes | | End Date | Yes | The system executes the saved SQL query, binding `:start_date` and `:end_date` to the values you entered. No SQL validation is performed — if your query does not support these parameters, the generation job will fail. The generated file appears in the report's output list tagged as **Manual** with a filename in the format: `{ReportName}_{YYYYMMDD}-{YYYYMMDD}.csv` If the SQL query does not include `:start_date` and `:end_date` parameters, the generation job will fail. Verify your query uses these exact parameter names before triggering a manual run. ### Manual vs Auto outputs All outputs — both scheduled and on-demand — appear in the same output list. Manual outputs are tagged **Manual** to distinguish them from scheduled runs. | Output type | Tag | Naming | | -------------------------------- | ------ | ---------------------------------------- | | Scheduled (daily/weekly/monthly) | Auto | `{ReportName}_{Period}.csv` | | On-demand (custom date range) | Manual | `{ReportName}_{YYYYMMDD}-{YYYYMMDD}.csv` | ## Audit trail Every manual generation attempt is captured in the audit trail with: * The user who triggered it * The start and end dates used * The run ID * Status (success or failure) * Timestamp Scheduled runs are also logged automatically. ## Permissions reference | Action | Who can do it | | -------------------------------------- | ----------------------------------------- | | Create report | Super Admins only | | Edit report (query, schedule, sharing) | Super Admins only | | View report and preview data | Any user with access per sharing settings | | Generate on-demand (manual run) | Any user with access per sharing settings | | Download output | Any user with access per sharing settings | ## Troubleshooting **Manual generation fails immediately.** * Check that your SQL query contains `:start_date` and `:end_date` parameters. Without them, the job cannot bind the date range and will fail. **Report preview shows unexpected results.** * Open Report Settings and review the SQL query. Check filter conditions, date field names, and JOIN logic. **Report is not visible to a team member.** * Open Manage Report Sharing and add their username or role. **Scheduled report is not generating.** * Verify the generation schedule is set (not Manual only). * Check the output list for any failed run entries and review error messages. # Reports & Analytics overview Source: https://help-loyalife.xoxoday.com/user-guides/reports/overview Measure and analyze your loyalty program's performance across transactions, members, communications, and custom SQL-based exports. The Reports & Analytics module gives you the data infrastructure to evaluate, optimise, and audit your loyalty program. Access pre-built dashboards for instant insights, run custom SQL queries for tailored analysis, schedule recurring exports, and download data for offline processing. ## Accessing reports Select **Reports & Analytics** from the left sidebar. The module is organised into two areas: | Area | Purpose | | ---------------- | -------------------------------------------------------------------------- | | **Data Exports** | Generate, schedule, and download report files across all report categories | | **Dashboards** | Real-time visual summaries of key program metrics | Reports — Data Exports screen showing Points Distribution summary (146M points, Redeemed/Expired/Balance breakdown), Storage Insight (17.76 MB used, 2033 reports), and report category tabs: Transactional, Members, Communication, Liability, Projected Expiry, Administrative Data, Logs, Custom Report, Gamification, Exported Data ## Report categories Reports are organised into eight categories, accessible as tabs under **Data Exports**: | Category | What it covers | | ----------------------- | ----------------------------------------------------------------------- | | **Transaction** | Point accruals, redemptions, reversals — every earn and debit event | | **Member** | Enrolment trends, balance snapshots, activity patterns | | **Communication** | Email and SMS delivery, open rates, campaign engagement | | **Projected Expiry** | Upcoming points expirations by month — for liability planning | | **Liability** | Total outstanding unredeemed points — your current financial obligation | | **Administrative Data** | Audit trail, user activity logs, configuration change history | | **Logs** | File upload processing status, errors, and rejected records | | **Custom Reports** | SQL-based reports with real-time preview and on-demand generation | See [Report types](/user-guides/reports/report-types) for a detailed breakdown of each category. See [Custom reports](/user-guides/reports/custom-reports) for SQL query reports, real-time preview, and custom date range generation. Create Report form for Transactional type showing Report Name field, Column selector with available and selected columns, Reporting Period dropdown, and Filters section for narrowing the data export ## What you can do * **View in real time** — preview report data directly in the dashboard without downloading a file (available for standard and custom reports) * **Schedule exports** — configure daily, weekly, or monthly automatic generation * **Download on demand** — generate and download a report for any supported date range * **Configure columns** — show only the columns relevant to your role; preferences persist across sessions * **Share reports** — custom reports can be shared with specific users or roles ## Dashboards The Dashboards view provides visual summaries of program performance: | Dashboard | Key metrics | | --------------------- | ---------------------------------------------------------- | | Member dashboard | Total enrolled, active vs inactive, new enrolments trend | | Transaction dashboard | Points issued, redeemed, expired — volume and trend charts | | Engagement dashboard | Campaign participation rates, communication open rates | Dashboards refresh automatically and do not require a manual download to stay current. ## Column customisation Every standard report table supports **Configure Columns**. You can: * Add optional columns to the display * Hide columns not relevant to your view * Preferences are saved per user and persist across sessions * Default (mandatory) columns cannot be removed ## Scheduled reports For recurring needs, configure a report to auto-generate: | Schedule | Frequency | | -------- | ------------------------ | | Daily | Generates every day | | Weekly | Generates once per week | | Monthly | Generates once per month | Scheduled outputs appear in the report's output list alongside any manual downloads, tagged by generation type. ## Permissions | Action | Required permission | | --------------------- | ------------------------------------------------------------------- | | View reports | View Reports | | Download reports | Download Reports | | Create custom reports | Create Custom Reports (Super Admin) | | View audit trail | View Audit Trail | | Export member PI data | PI Data Access (requires separate toggle in Advanced Configuration) | Use **Projected Expiry** and **Liability** reports together for financial planning. Expiry reports show when points leave the ledger; Liability reports show your current total obligation. Together they give you a forward-looking view of redemption pressure. # Report types Source: https://help-loyalife.xoxoday.com/user-guides/reports/report-types Reference guide to every Loyalife report category — transactional, member, liability, expiry, and more with recurring schedules and use cases. Loyalife organises reports into nine categories under **Reports & Analytics**. Each category has its own tab. Reports can be generated on-demand for a custom date range, or scheduled to run automatically at a set frequency. ## Report frequencies All report types support these scheduling options: | Frequency | Value | Description | | -------------------- | :---: | --------------------------------------------------------------------------------------------------- | | Daily | 1 | Generated each day for the previous day's data | | Weekly | 2 | Generated each Monday for the previous week | | Monthly | 3 | Generated on the 1st for the previous month | | Quarterly | 4 | Generated at quarter-end | | Yearly | 5 | Generated at year-end | | One Time Report | 6 | Single run for a specific date range | | Custom Monthly Range | 7 | Monthly generation with a custom start/end day within the month (e.g., 15th to 14th billing cycles) | **Custom Monthly Range** is designed for programs with billing cycles that don't align with calendar month boundaries — for example, a program that closes on the 15th and opens on the 16th. ## Report views Within each category, three sub-views exist: | View | Description | | --------------------------- | --------------------------------------------------------------- | | **Recurring Report** | Scheduled reports — configure frequency, recipients, and format | | **Custom Generated Report** | One-time reports generated for a specific date range | | **Report Data** | Previously generated report files available to download | *** ## Transactional reports Tracks every points activity event in the program — every credit and debit entry on the points ledger. **When to use:** * Audit point accrual to verify rules are applying correctly * Investigate a disputed transaction for a specific member * Reconcile total points issued for a period against Rule Engine activity * Identify unusually high-value transactions for fraud review ### Transaction categories When setting up a Transactional report, the **Transaction Category** filter narrows the output to a specific type of ledger movement. Selecting a category excludes all other movement types from the report. | Category | Direction | Points ledger entry produced by | | --------------------------------- | --------- | ------------------------------------------------------------------------------------- | | **Credit By Accrual** | Credit | Rule Engine evaluating a submitted transaction and finding a matching rule | | **Debit By Redemption** | Debit | A member redeeming points for a reward through the app | | **Credit By Bonus** | Credit | Campaign bonus, tier bonus, referral bonus, or admin manual credit | | **Debit By Expiration** | Debit | Points reaching their expiry date under the program's expiry policy | | **Debit By Bonus** | Debit | Manual debit adjustment or accrual reversal by an admin | | **Debit By Cancellation** | Debit | Points reversed when a transaction or order is cancelled | | **Debit By Reversal** | Debit | Previously accrued points clawed back by the system or admin | | **Credit By Reversal** | Credit | Points restored to a member's balance after a prior debit is reversed | | **Debit By On Behalf Redemption** | Debit | A redemption completed by an authorised agent acting on behalf of a member | | **Credit by Point Purchase** | Credit | Points credited when a member directly purchases points with currency | | **Credit Transfer** | Credit | Points transferred into a member's account from an external source or another account | | **Redemption Reversal** | Credit | Points restored after a redemption is reversed or cancelled | *** #### Credit By Accrual Points are credited each time the Rule Engine evaluates a submitted transaction and a matching earning rule fires. The transaction can arrive via the real-time API or from a TXN batch file uploaded over SFTP. **How it works:** 1. A transaction is submitted with the member's Relation Reference, transaction amount, transaction type, and any custom attributes. 2. The Rule Engine checks every active rule group the member belongs to. 3. For each rule whose IF conditions are satisfied, the THEN reward (fixed points, multiplier, or percentage) is calculated and posted. 4. One credit entry per matching rule is written to the ledger, tagged as `Credit By Accrual`. **Use cases:** * Reviewing which transactions triggered which rules during a specific period * Reconciling points issued against transaction volume * Auditing accrual activity for a specific member or transaction type **Produced by:** Rule Engine → [Configuring rules](/user-guides/rule-engine/configuring-rules), [Data processing (TXN file)](/user-guides/rule-engine/data-processing), [Insert Transaction API](/api-reference/transactions/insert-transaction) *** #### Debit By Redemption Points are debited each time a member exchanges their balance for a reward. Loyalife validates the member's available balance before processing the redemption — if the balance is insufficient, the redemption is rejected and no debit entry is created. **How it works:** 1. Member initiates a redemption through the mobile app (Plum marketplace, partner catalogue, or cash-equivalent redemption). 2. Loyalife confirms the balance covers the redemption amount. 3. Points are debited and the reward is fulfilled. 4. The debit entry is tagged as `Debit By Redemption` with the reward type in the Narration field. **Use cases:** * Tracking total redemption volume and value over a period * Identifying which reward categories are most popular * Reconciling points redeemed against fulfillment records **Negative balance:** Redemption is blocked if the member's balance is less than the redemption amount. `Debit By Redemption` entries cannot result in a negative balance. **Produced by:** [Plum marketplace](/user-guides/marketplace/plum), [On-behalf redemption](/user-guides/marketplace/on-behalf-redemption), [Redeem Points API](/api-reference/payment-gateway/redeem-points) *** #### Credit By Bonus Bonus credits cover all point grants that originate outside the standard Rule Engine accrual flow. The ledger Narration field identifies the specific source. | Bonus source | How the credit is generated | | -------------------------- | ---------------------------------------------------------------------------------------- | | **Campaign bonus** | A broadcast or triggered campaign awards a fixed point amount to members in a segment | | **Tier achievement bonus** | A member qualifies for a new tier and the tier is configured to award entry-bonus points | | **Referral bonus** | A member's referral converts and the referrer earns their reward | | **Manual credit** | An admin manually credits points from the member profile using the narration **Bonus** | | **BNS file upload** | A batch bonus file is uploaded; each row credits points directly without rule evaluation | **Use cases:** * Measuring the total bonus points distributed by campaigns vs. tier upgrades vs. referrals * Auditing manual point adjustments made by admins * Reconciling bonus file upload outcomes against the BNS file record count **Produced by:** [Broadcast campaigns](/user-guides/engage/broadcast-campaigns), [Triggered campaigns](/user-guides/engage/triggered-campaigns), [Tiers](/user-guides/tiers/configure-tiers), [Referrals](/user-guides/referrals/overview), Member profile manual adjustment, [Data processing (BNS file)](/user-guides/rule-engine/data-processing) *** #### Debit By Bonus Debit bonus entries cover point deductions that are corrections or reversals rather than redemptions. These are always admin-initiated and recorded as a manual debit in the member's transaction history. | Debit scenario | What happens | | --------------------------- | ----------------------------------------------------------------------------------------------------------- | | **Accrual reversal** | A previously accrued transaction is reversed — points that were credited are taken back | | **Manual debit adjustment** | An admin deducts points with narration **Bonus** to correct a prior over-credit or compensate for a dispute | **Negative balance:** Unlike redemptions, Debit By Bonus entries are **not blocked** when the debit amount exceeds the member's available balance. If an admin enters a debit larger than the current balance, the balance goes negative. A negative balance is visible in the member's profile and in reports. This is intentional — it allows corrections for over-credited points without being constrained by the current balance. **Use cases:** * Reviewing all point deductions applied by admins during a period * Auditing accrual reversals linked to dispute resolutions * Identifying members with negative balances caused by correction debits **Produced by:** Member profile manual adjustment (debit direction), Maker-Checker approved debit transactions *** #### Debit By Expiration Points are debited automatically when they reach their scheduled expiry date. The expiry policy — period, schedule, and scope — is configured in Program Settings. Expiry runs as a system batch process; no admin action is needed. **How it works:** 1. Each credit entry on a member's ledger carries an expiry date, calculated at the time the credit is posted based on the program's expiry configuration. 2. On the scheduled expiry run, the system identifies all point batches whose expiry date has passed. 3. Any unexpired balance within those batches is debited. The entry is tagged as `Debit By Expiration`. **Use cases:** * Measuring how many points expired in a period versus how many were redeemed (liability conversion efficiency) * Forecasting redemption pressure ahead of large expiry events (use with Projected Expiry report) * Identifying members whose balances dropped to zero due to expiry — candidates for re-engagement **Negative balance:** Not possible. Only points that were previously credited can expire. The expiry debit can equal but never exceed the available balance of the relevant credit batch. **Produced by:** Program Settings → Points & Expiry configuration (see [Advanced configuration](/user-guides/configuration/advanced-configuration)) *** #### Debit By Cancellation Points are debited when a qualifying transaction is cancelled after points have already been credited for it. The debit claws back only the points that were awarded for the cancelled transaction — other accruals on the member's account are unaffected. **How it works:** 1. A transaction is submitted and points are credited (Credit By Accrual). 2. The transaction is subsequently cancelled — either by the merchant, the partner system, or via an admin action. 3. Loyalife posts a matching debit entry tagged as `Debit By Cancellation`, netting the member's balance back to its pre-accrual state. **Use cases:** * Reconciling cancelled orders that resulted in points being temporarily credited then reversed * Auditing cancellation activity to detect abnormal cancellation patterns * Verifying the balance impact of a specific cancellation event for a member dispute **Negative balance:** Not expected under normal operation — the debit is bounded by the points credited for that transaction. A negative balance would indicate the original credit was already partially or fully consumed before the cancellation debit posted. *** #### Debit By Reversal A previously accrued points credit is reversed and removed from the member's balance. This is distinct from a cancellation — reversals are typically driven by data corrections, fraud findings, or administrative decisions rather than a transaction-level cancel event. **How it works:** 1. An accrual event was previously posted (Credit By Accrual or Credit By Bonus). 2. An admin or system process determines the credit was incorrect. 3. A reversal debit is posted, reducing the balance by the reversed amount. **Use cases:** * Auditing how many points were reversed in a period and by which admin * Identifying members whose balances were reduced by reversals * Reconciling reversal activity against dispute resolution records **Negative balance:** Possible if the member's balance at reversal time is lower than the reversal amount — for example, if the member redeemed points between the original credit and the reversal. A negative balance resulting from a reversal is valid and expected in these cases. *** #### Credit By Reversal Points are credited back to a member's account when a prior debit — such as an expired points debit or an incorrectly applied debit — is itself reversed. This restores the balance to its state before the erroneous debit. **How it works:** 1. A debit entry was previously posted (any debit category). 2. The debit is determined to be incorrect or requires reversal. 3. A credit entry is posted, tagged as `Credit By Reversal`, restoring the reversed amount. **Use cases:** * Tracking corrections made to erroneous debit entries * Auditing admin-initiated balance restorations * Verifying that a specific debit has been fully offset by its reversal credit *** #### Debit By On Behalf Redemption Points are debited when an authorised agent completes a redemption acting on behalf of a member. The mechanics are the same as a standard redemption — balance is checked, points are debited, reward is fulfilled — but the entry is separately tagged so on-behalf activity is distinguishable from self-service redemptions in reports. **How it works:** 1. An agent with the On Behalf Redemption permission launches a marketplace session on a member's profile. 2. The agent selects and completes a redemption. 3. The debit is posted as `Debit By On Behalf Redemption` with the agent's identity recorded in the audit trail. **Use cases:** * Measuring the volume of redemptions assisted by support or relationship managers * Auditing which agents are performing on-behalf redemptions and for which members * Separating self-service redemption behaviour from agent-assisted behaviour in analytics **Negative balance:** Not possible — the same balance validation that applies to self-service redemptions applies here. **Produced by:** [On-behalf redemption](/user-guides/marketplace/on-behalf-redemption) *** #### Credit by Point Purchase Points are credited when a member purchases points directly using currency — for example, topping up their balance via a payment. This is separate from earning points through transactions; the member is explicitly buying points. **Use cases:** * Tracking revenue generated from point purchase transactions * Identifying members who actively buy points to reach redemption thresholds * Reconciling purchased points volume against payment gateway records *** #### Credit Transfer Points are transferred into a member's account from an external source — for example, from a partner programme, a migration event, or a peer-to-peer transfer where this member is the recipient. **Use cases:** * Auditing inbound point transfers from partner integrations * Reconciling balance migrations from a legacy loyalty programme * Reviewing peer-to-peer transfer receipts (paired with the sender's Debit entry) *** #### Redemption Reversal Points are restored to a member's account when a completed redemption is reversed or cancelled after the fact — for example, a voucher that was never fulfilled, or a redemption that was found to be erroneous. **How it works:** 1. A redemption was completed and a `Debit By Redemption` entry was posted. 2. The redemption is subsequently reversed — either by the fulfilment partner, a support action, or a system correction. 3. A credit entry is posted, tagged as `Redemption Reversal`, restoring the debited points. **Use cases:** * Tracking how many redemptions were reversed in a period and the points restored * Reconciling voucher fulfilment failures that required balance restoration * Auditing reversal activity by support agents for disputed redemptions **Produced by:** Admin reversal action on a member's redemption, [Reversal Points API](/api-reference/payment-gateway/reversal-points) *** ## Member reports Provides a snapshot and trend view of the member base. **What's included:** * Enrollment status and enrollment dates * Activation dates * Current tier for each member * Current point balance per member * Activity trends — active vs. dormant member counts over time **When to use:** * Identify dormant members for re-engagement campaigns * Track program growth (new enrolments per period) * Prepare a member count snapshot for stakeholder reporting *** ## Communication reports Monitors messaging performance across email, SMS, WhatsApp, and push notification channels. **What's included:** * Delivery status per message (delivered, failed, bounced) * Open rates for email communications * Click-through rates (where tracking links are used) * Channel-level breakdown (email vs. SMS vs. WhatsApp vs. push) * Campaign-level aggregates — total sends, delivery rate, engagement rate **When to use:** * Assess which message types or subjects get the highest open rates * Identify delivery failures and clean invalid contact data * Measure campaign communication effectiveness * Compare channel performance (email open rate vs. push tap rate) *** ## Liability reports Tracks the total outstanding unredeemed points across the program — the current financial obligation to members. **What's included:** * Total unredeemed points balance across all active members * Per-tier breakdown of liability * Historical liability trend by month * Points issued vs. points redeemed over time **When to use:** * Financial planning and accounting reconciliation * Tracking changes in liability over time * Assessing redemption pressure on the program * Monthly close reporting for finance teams *** ## Projected Expiry reports Estimates upcoming points expiration, organised by month. **What's included:** * Points scheduled to expire each month, broken down by member group or tier * Total expiry value per period * Expiry distribution by earning date cohort **When to use:** * Forecast how many points will leave the ledger each month * Plan a redemption-nudge campaign before a large expiry event * Model the impact of changing your expiry policy Run a re-engagement campaign 4–6 weeks before a large projected expiry month to convert expiring points into redemptions — this improves member satisfaction and reduces wasted liability. *** ## Administrative Data reports System-level and operational logs for compliance and governance. **What's included:** * Audit trail — every administrative action with actor, timestamp, and before/after values * User activity monitoring — logins, configuration changes, data access events * Configuration change history — program settings, rule changes, tier updates * Maker-Checker workflow history — all approvals and rejections with actors **When to use:** * Compliance and internal audit reviews * Investigating unauthorized or unexpected changes * Verifying separation of duties in approval workflows * Preparing for regulatory audits *** ## Logs Detailed system activity history for technical and operational troubleshooting. **What's included:** * File upload history and processing status for TXN, CPD, and BNS files * Records of rejected rows and the reason for rejection * Error logs with error codes for failed processing * API call logs (where enabled) **When to use:** * Diagnose why a TXN file upload processed fewer records than expected * Identify which rows failed processing and why * Verify file upload timing for SLA monitoring *** ## Custom reports Build personalised data views using SQL queries with complete control over fields, filters, and date ranges. **Key capabilities:** * Write any SQL query against your Loyalife data schema * Preview report results in real time without downloading a file * Configure recurring schedules (daily, weekly, monthly) * Generate one-time reports for custom date ranges on demand * Control who can access each report via sharing settings See [Custom reports](/user-guides/reports/custom-reports) for full documentation. Creating custom reports requires Super Admin access. Viewing, previewing, and generating on-demand exports is available to any user with access per the report's sharing settings. *** ## Gamification reports Tracks member participation and outcomes from gamification campaigns — scratch cards, spin-the-wheel, and other game mechanics. **What's included:** * Game participation events — who played, when, and which game * Reward outcomes — points or vouchers awarded per play * Campaign performance — total plays, win rate, points distributed * Member-level game history **When to use:** * Evaluate the effectiveness of a gamification campaign * Identify members who have played but not yet won (targeting opportunity) * Calculate total points issued through gamification vs. standard rules * Analyse engagement lift from game campaigns Gamification reports only appear if the Gamification module is enabled in **Configuration → Modules**. *** ## Exported Data reports Provides access to bulk data exports generated through the Loyalife export pipeline — member data, transaction history, segment outputs, and other large datasets. **What's included:** * Bulk member data exports (status, balance, tier, attributes) * Transaction history exports * Segment membership exports * Custom data exports requested via the platform or API **When to use:** * Share full member data with an external analytics tool or CRM * Extract historical transaction data for data warehouse ingestion * Prepare large datasets for offline analysis that would be too large for in-portal custom reports * Verify a bulk export completed successfully and download the output file *** ## Report access control Report visibility is controlled by the `viewReports` permission. All report categories use the same base permission — granular per-category access is controlled by your administrator. | Who can see | Behavior | | --------------------------- | ------------------------------------------------------------------ | | Users with `viewReports` | Can access all report tabs and download generated files | | Users without `viewReports` | Reports section is hidden from the sidebar | | Super Admins | Can additionally create custom reports and manage report schedules | # Visual dashboards Source: https://help-loyalife.xoxoday.com/user-guides/reports/visual-dashboards See how Loyalife's Superset-powered dashboards surface mobile app usage, member behavior, and channel partner performance in real time. Visual Dashboards are built on Apache Superset and provide rich, interactive analytics beyond the standard tabular reports. They are embedded directly inside the Loyalife admin portal — no separate login or navigation to an external tool is required. ## Accessing dashboards Navigate to **Reports & Analytics → Dashboards** in the left sidebar. Dashboards are listed as cards. Click any card to open the interactive dashboard embedded in the page. Program Overview Dashboard showing Active Campaigns count, Total Cashback amount, and a Total Card Usage area chart with monthly trend data, alongside filter controls for date range and program selection Access is permission-controlled. The `superset` permission on a user's role determines whether the Dashboards menu item is visible. Contact your Loyalife administrator to enable access. ## Pinning a dashboard to the overview Frequently used dashboards can be pinned to the **Loyalty Overview** home screen so they load immediately when you log in. To pin a dashboard, open it and use the pin option from the dashboard menu. ## Data sources Dashboards pull from two pipelines: | Source | Data | Refresh cadence | | ------------------------------------- | ----------------------------------------------------------------- | ------------------ | | **Firebase Analytics** (via BigQuery) | Mobile app usage — DAU, sessions, new users, geographic breakdown | Daily sync at 2 AM | | **Loyalife transaction database** | Points earned, redeemed, invoices uploaded, claims approved | Near real-time | Dashboards are automatically filtered to the currently selected program — the program ID is passed at embed time, so you only see data for your program without any manual filtering. ### Firebase Analytics pipeline Firebase events from all client mobile apps (Android, iOS, Web) flow into a shared BigQuery dataset. A nightly pipeline maps each app (`bundle_id + platform`) to its Loyalife program and writes results to the analytics database Superset queries. The pipeline supports: * **Per-program breakdown** — data is separated by bundle ID and platform * **Gap recovery** — if a day is missed, the pipeline automatically backfills all missing dates on the next run * **Manual backfill** — administrators can trigger a backfill for a specific date without disrupting the regular schedule ## Available dashboards ### Mobile app usage | Metric | Description | | ---------------------------- | ------------------------------------------------------------ | | **DAU** (Daily Active Users) | Unique users who opened the app at least once on a given day | | **Sessions** | Total app sessions | | **New users** | Users who launched the app for the first time that day | | **Country / city** | Geographic breakdown of usage | Available per program, per platform (Android, iOS, Web), and per time range. ### Channel partner dashboards For programs with channel partners: | Dashboard | What it shows | | ------------------------------- | ----------------------------------------------------------------------------- | | **Invoice uploads by retailer** | Volume and trend of invoice submissions per partner | | **Earned points by retailer** | Points credited per partner — identifies top performers and inactive partners | ### Program performance * Points issued vs. redeemed over time * Member tier distribution * Redemption category breakdown * Acquisition source split (referral vs. organic) ## Interacting with dashboards ### Filters Every dashboard includes a filter bar. Common filters: | Filter | Description | | -------------- | ------------------------------------------------ | | **Date range** | Adjusts the time window for all charts | | **Platform** | Android, iOS, or Web (for mobile app dashboards) | | **Partner** | Filters to a specific channel partner | Click **Apply filters** after making selections. Filters persist within your session. ### Drill-down Most charts are interactive — click a bar, segment, or data point to drill into detail. For example, clicking a country on the DAU map opens a city-level breakdown. ### Exporting data 1. Hover over a chart 2. Click the **⋮** menu 3. Select **Export to CSV** or **Download PNG** For full dashboard exports, use the **PDF** option from the dashboard-level menu. ## Troubleshooting **Dashboard shows no data for recent days.** * The Firebase pipeline runs at 2 AM. Yesterday's data is available after that run completes. * If data is missing for more than one day, the pipeline may have failed. Contact your Loyalife administrator to trigger a manual backfill. **A program's data is not appearing.** * The program may not have Firebase Analytics configured for its app. Confirm with your technical team that `analytics_sync_config` includes the program's bundle IDs. **Dashboards menu is not visible.** * Your role may not have the `superset` permission. Ask your Loyalife administrator to enable dashboard access for your role. # Attributes Source: https://help-loyalife.xoxoday.com/user-guides/rule-engine/attributes Understand Loyalife's attribute types covering global and custom transaction fields, member profile data, and computed aggregate metrics to build precise conditions in earning rules. Attributes are the building blocks of rule logic. Every condition in the Rule Engine references an attribute — a named piece of data that carries a value at evaluation time. Loyalife supports four categories of attributes, each serving a different purpose. Rule conditions combine attributes from **both transactions and members** in a single rule — what happened in the transaction and who the member is. ## Attribute categories ### Global transaction attributes The seven **global transaction attributes** are built into every Loyalife program and are present on every transaction. They cannot be removed. | Attribute | API / file key | Data type | Mandatory | Description | | ------------------ | :-------------------------: | :-------: | :-------: | ---------------------------------------------------------------------------------------------- | | Transaction Id | `transaction_id` | String | Yes | Unique identifier for the transaction — used for deduplication | | Transaction Date | `transaction_date` | Date | Yes | Date (and optionally time) of the transaction. Supports combined date+time conditions in rules | | Transaction Amount | `amount` | Decimal | Yes | Monetary value of the transaction in the program currency | | Product Code | `product_code` | Selection | Yes | Product category classification — values are configured per program | | Sub Product Code | `sub_product_code` | Selection | No | Subcategory within the product code | | Relation Reference | `member_relation_reference` | String | Yes | The member's unique identifier — links the transaction to their account | | Transaction Type | `transaction_type` | Selection | Yes | Direction of the transaction: `CR` (credit/earn) or `DR` (debit/redemption) | Product Code and Sub Product Code are **selection** type — the allowed values are a configurable picklist. For these attributes, the "Match attribute" comparison is not available; only fixed value selection is supported. ### Custom transaction attributes Beyond the seven global attributes, you can define **additional transaction attributes** specific to your program. These are configured in **Rule Engine → Attributes** and must be submitted with each transaction via API or TXN file. Common examples: | Custom attribute | Example use in a rule | | ---------------- | ------------------------------------------------------ | | Merchant Name | `IF Merchant Name ilike "Fuel" THEN 2x points` | | MCC Code | `IF MCC Code = 5411 (grocery) THEN 1.5x points` | | Channel | `IF Channel = "Online" THEN bonus 50 points` | | Store ID | `IF Store ID in_group [premium_stores] THEN 3x points` | | Currency | `IF Currency = "USD" THEN apply FX rule` | To create a custom transaction attribute, go to **Rule Engine → Attributes → Add Attribute** and select "Transaction" as the attribute type. Once saved, the attribute appears in the Rule Engine condition builder and must be supplied in every transaction submission that should have it evaluated. ### Member attributes (global) The nine built-in member profile fields available in every program. These are set at enrollment and updated via API or the member profile in the admin portal. | Attribute | Data type | | ------------------ | ----------- | | Relation Reference | String | | Full Name | String | | Email | String (PI) | | Phone | String (PI) | | Address | String (PI) | | Gender | String (PI) | | Date of Birth | Date (PI) | | Status | String | | Preferred Language | Selection | ### Custom member attributes Any additional member-level fields you define for your program — occupation, product preference, dealer tier, etc. Configured in **Members → Attributes**. Once created, they appear automatically in the Rule Engine condition builder and in Segment filters. ### Aggregate attributes Computed metrics derived from transaction history. The Rule Engine calculates these dynamically at evaluation time. | Attribute | Description | Example value | | -------------------------- | -------------------------------------------- | ------------- | | Monthly Spend Sum (MTD) | Total transaction amount this calendar month | ₹18,500 | | Transaction Count (MTD) | Number of transactions this calendar month | 7 | | Average Transaction Value | Average spend over recent transactions | ₹2,642 | | Lifetime Spend Sum | Total spend since enrollment | ₹2,34,000 | | Lifetime Transaction Count | Total number of transactions ever | 89 | Aggregate attributes appear automatically in the Rule Engine condition builder and in Segment filters. Any new aggregate attribute you define will appear in both places without additional configuration. **Key aggregate evaluation rules:** * The current transaction is included in the aggregate count/sum **before** rule evaluation * Reversals and refunds are automatically subtracted from aggregates * Aggregation runs at the account level — transactions from primary and supplementary cards are counted together #### Aggregate time periods When creating an aggregate attribute, you select the time window over which it is calculated: | Period | Internal value | Description | | ------------------------- | :------------: | ---------------------------------------------------------------------------------------------- | | **Lifetime** | 1 | Computed from the member's enrollment date to now — never resets | | **Month to Date (MTD)** | 2 | Resets on the first of each calendar month | | **Quarter to Date (QTD)** | 3 | Resets at the start of each calendar quarter (Jan/Apr/Jul/Oct) | | **Year to Date (YTD)** | 4 | Resets on January 1st each year | | **Rolling** | 5 | A sliding window of N days back from the current date (e.g., last 30 days, last 90 days) | | **Billing Cycle** | 6 | Follows the program's configured billing cycle start/end dates rather than calendar boundaries | Choose **Billing Cycle** for programs where the calculation period aligns with statement or billing periods rather than calendar months. The billing cycle start date is configured in **Configuration → Calculation Settings**. #### Aggregate functions Each aggregate attribute applies a statistical function across qualifying transactions in the selected time window: | Function | Description | | --------- | ----------------------------------------------------- | | **sum** | Total of all values (e.g., total spend, total points) | | **count** | Number of qualifying transactions | | **max** | Highest single value in the period | | **min** | Lowest single value in the period | | **avg** | Average value per transaction in the period | ### Using attributes in rule conditions In the Rule Engine condition builder, every condition selects: 1. **An attribute** (from any category above) 2. **An operator** (equals, greater than, between, is multiple of, etc.) 3. **A value** — either a static input or another attribute (for dynamic comparisons like birthday rules) **Date attribute type modifiers:** When a date attribute is selected, you can further specify what part of the date to compare: | Type modifier | Compares | | ------------- | -------------------------------------- | | Full date | Complete date value (e.g., 04/22/2026) | | Date of Month | Just the day number (1–31) | | Month of Year | Just the month number (1–12) | | Year | Just the year | | Day of Week | Monday, Tuesday, etc. | This allows rules like "transaction on the same day-of-month as the member's birthday" without needing to know which month. ## Accessing the Attributes Manager Manage Attributes screen showing Global Attributes (Transaction Id, Transaction Date, Transaction Amount, Product Code, Sub Product Code, Relation Reference, Transaction Type) and Local Attributes section below for custom transaction attributes Select **Rule Engine** from the left sidebar. Click the **settings icon** in the upper-right corner of the Rule Engine screen. The Attributes Manager lists all attributes configured for your program, organized by category. ## Creating a custom attribute Choose the attribute category: Transaction (local) or Member (custom). | Field | Description | | ----------------- | ------------------------------------------------------------------------ | | Attribute name | The label used in the Rule Engine condition builder | | Data type | String, Number, Boolean, Date — determines which operators are available | | API / File key | The exact field name used when submitting data via API or TXN file | | Unique constraint | Whether values must be distinct across records | | Mandatory | Whether a value is required for every transaction | | PI flag | Mark as personally identifiable — controls export permissions | Click **Save**. The attribute is immediately available in rule conditions and segment filters. New aggregate attributes you create are automatically available in both the Rule Engine condition builder and in Segment filters — no additional steps required. An attribute's data type **cannot be changed** after it has been used in a live rule. Plan your data model carefully before publishing rules that depend on a new attribute. A wrong data type will require creating a new attribute and migrating any rules that referenced the old one. ## Attribute data types and compatible operators | Data type | Compatible operators | | ----------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Number** | `=` (equals), `!=` (not equals), `>` (greater than), `>=` (greater than or equal), `<` (less than), `<=` (less than or equal), in\_group, not\_in\_group, is\_multiple\_of | | **String** | = (equals), ilike (contains / case-insensitive match), not ilike (does not contain), is null (no value set), is not null (value is set), in\_group, not\_in\_group | | **Date** | On (exact date match), Not on, After, Before | | **Boolean** | Equals, Not Equals | **Operator notes:** | Operator | Notes | | --------------------------- | -------------------------------------------------------------------------------------------------------------------- | | `ilike` | Case-insensitive substring match — e.g., merchant name `ilike` "fuel" matches "Shell Fuel" and "FUEL MART" | | `not ilike` | Excludes records containing the substring | | `is null` / `is not null` | Checks whether the attribute has any value set — useful for filtering members with missing profile fields | | `in_group` / `not_in_group` | Matches against a pre-defined list or group of values; useful for MCC code lists, product code whitelists/blacklists | | `is_multiple_of` | Fires the rule when the aggregate value is a multiple of the threshold (e.g., every 10th transaction) | **Date condition type modifiers (for recurring date rules):** When using date attributes in recurring or comparative conditions, you can specify which portion of the date to evaluate: | Type modifier | Compares | | ------------- | ---------------------------- | | Full date | Complete date value | | Day of Month | Just the day number (1–31) | | Month of Year | Just the month number (1–12) | | Day of Week | Monday, Tuesday, etc. | ## Troubleshooting **An attribute is not appearing in the Rule Engine condition builder.** * Verify the attribute is saved and active in the Attributes Manager. * Check that the data type is compatible with the condition you're trying to build. **Aggregate values are not matching expected transaction totals.** * Remember that the current transaction is included in the aggregate before evaluation. * Reversals and refunds are subtracted — check whether any reversals occurred in the calculation period. * Verify the aggregate's period definition (MTD means month-to-date, which resets on the first of each month). # Rule configuration walkthrough Source: https://help-loyalife.xoxoday.com/user-guides/rule-engine/configuring-rules End-to-end walkthrough for setting up Loyalife earning rules — from defining attributes to enrolling members and going live. Rules don't exist in isolation. They depend on attributes to know what to evaluate, on members to know who earns, and on rule groups to know which members a set of rules applies to. Before the first transaction is processed, each layer must be in place. This guide walks through every step in the correct sequence. ## The setup dependency chain ``` Program configuration └── Define member attributes (global + custom) └── Define transaction attributes (global + custom) └── Enroll members (CPD file or API) └── Create rule groups (+ caps) └── [optional] Create segments → link to rule group └── Create earning rules (IF conditions + THEN reward) └── Submit transactions (TXN file or API) └── Points awarded to members ``` Each layer depends on the one above it. Attributes must be defined before rules reference them. Members must be enrolled before transactions can be attributed to them. Rule groups must exist before transactions are evaluated. Segments are **not required**. A rule group with no linked segment applies to every member in the program. Only create segments when you need rules to target a specific subset of members. *** ## Phase 1 — Program configuration Before attributes or rules, your program's foundational settings must be in place. Navigate to **Configuration → Program Settings** and verify: | Setting | Why it matters for rules | | ------------------------ | ------------------------------------------------------------------------------------- | | Points currency | Determines the unit used in rule rewards (points, miles, cashback %) | | Product codes | The allowed values for the `Product Code` attribute — rules can filter by these | | Sub product codes | The allowed values for `Sub Product Code` — used for finer transaction classification | | Billing cycle start date | Required if you plan to use **Billing Cycle** aggregate attributes in rules | | Expiry configuration | If rules award expiry-tagged points, expiry settings must be configured first | Product Code and Sub Product Code are **selection** attributes — their allowed values come from the configured picklist. If a rule condition needs to check `Product Code = "Retail"`, the value `Retail` must exist in the picklist before the rule can reference it. *** ## Phase 2 — Define your data model This is the most important planning step. Attributes are the vocabulary your rules speak. Every condition in a rule references an attribute. Get the data model right before building rules — changing an attribute's data type after it is used in a live rule requires creating a new attribute and migrating all rules that referenced the old one. ### 2a. Member attributes Nine global member attributes (Relation Reference, Full Name, Email, Phone, Address, Gender, Date of Birth, Status, Preferred Language) are available in every program without any setup — see [Member Attributes](/user-guides/members/attributes) for the full reference. For program-specific member data, define **custom member attributes** at **Members → Attributes → Add Attribute**. **Before creating custom attributes, answer:** * What member-level facts do my rules need to check? (card type, dealer tier, KYC status) * What member-level fields do my segments need to filter on? (region, product holding, enrollment channel) * What columns does my CPD file contain beyond the standard fields? **Example — retail bank loyalty program:** | Custom attribute | API / file key | Data type | Used for | | ---------------- | :---------------: | :-------: | --------------------------------------------------------------- | | Card Type | `card_type` | String | Segment: premium cardholders; Rule: 2x points for Platinum card | | Product Holding | `product_holding` | String | Rule: bonus points for savings account transactions | | KYC Status | `kyc_status` | String | Segment: exclude unverified members from promotions | | Home Branch | `home_branch` | String | Communications: insert nearest branch in push notifications | ### 2b. Transaction attributes Seven global transaction attributes are present on every transaction: | Attribute | API / file key | Data type | | ------------------ | :-------------------------: | :-----------------: | | Transaction Id | `transaction_id` | String | | Transaction Date | `transaction_date` | Date | | Transaction Amount | `amount` | Decimal | | Product Code | `product_code` | Selection | | Sub Product Code | `sub_product_code` | Selection | | Relation Reference | `member_relation_reference` | String | | Transaction Type | `transaction_type` | Selection (CR / DR) | For transaction-level data beyond these seven, define **custom transaction attributes** at **Rule Engine → Attributes → Add Attribute** (not under Members). **Before creating custom transaction attributes, answer:** * What transaction-level data should rules evaluate? (merchant name, MCC code, channel, store) * What columns does my TXN file send beyond the standard seven? * What fields does the transaction API payload include? **Example — retail bank loyalty program:** | Custom attribute | API / file key | Data type | Used for | | ------------------- | :-------------: | :-------: | --------------------------------------------------- | | MCC Code | `mcc_code` | Number | Rule: 1.5x points at grocery stores (MCC 5411) | | Transaction Channel | `channel` | String | Rule: +50 flat points for online transactions | | Merchant Name | `merchant_name` | String | Rule: 3x at specific merchant (`ilike "Brand X"`) | | Currency | `currency` | String | Rule: apply FX rate adjustment for foreign currency | The **API / file key** you set here is the exact field name that must appear in every TXN file column header and every API payload key for this attribute. A mismatch means the attribute arrives as null — the rule condition sees no value and evaluates to false. *** ## Phase 3 — Enroll members Members must exist in Loyalife before any transaction can be attributed to them. Two methods: ### CPD file (bulk enrollment) Upload a CPD file via SFTP to `upload/CPD`. Each row is one member. For new members, set `Action Type = N`. Required columns: ``` action_type | relation_reference | member_name | [optional: address, mobile, email, dob, gender, language] | [+ any custom member attribute columns defined in Step 2a] ``` The column name for each custom attribute must exactly match the **API / file key** configured in Members → Attributes. After upload, each member has: * A Loyalife account linked to their Relation Reference * Global and custom attributes populated from the file * A starting balance of zero * Aggregate attributes initialised at zero (they build as transactions arrive) ### API (real-time enrollment) Use the [Create Member Profile](/api-reference/members/create-profile) endpoint to enroll members from your application as they register. The same attribute mapping applies — API keys must match what was configured in Members → Attributes. *** ## Phase 4 — Create rule groups Go to **Rule Engine → Create Rule Group**. Give the group a name, optionally link it to a segment (leave blank to apply to all members), and set any caps you need. See [Rule Groups](/user-guides/rule-engine/rule-groups) for the full field reference and cap behaviour. The key structural decision is how many groups you need and how to divide them. A group per logical earning category keeps them independently manageable — you can pause a promotional group without touching base earning. **Example structure:** ``` Rule Group: Base Earning → no segment (all members), monthly cap 10,000 pts Rule Group: Platinum Benefits → segment: Premium Card, monthly cap 5,000 pts Rule Group: New Member Welcome → segment: New Members, lifetime cap 2,000 pts Rule Group: Weekend Promotions → no segment (all members), monthly cap 3,000 pts ``` A member can earn from multiple rule groups simultaneously. A Platinum cardholder buying something on a Saturday earns from Base Earning AND Platinum Benefits AND Weekend Promotions in the same transaction — each group's caps are tracked independently. *** ## Phase 5 — Create earning rules Each rule group can contain one or more earning rules. Every rule is an IF / THEN statement evaluated against each transaction. Go to **Rule Engine → \[select a rule group] → Add Rule**. Add New Rule form showing Rule Details at the top (rule name, version, sequence), followed by Set Rule Conditions with IF attribute/operator/value dropdowns and AND/OR condition builders, and a THEN Points section with reward type selector ### IF conditions Each condition has three parts: an **attribute**, an **operator**, and a **value**. | Part | Options | | --------- | ------------------------------------------------------------------------------------------------------------------------ | | Attribute | Any transaction attribute (global or custom), any member attribute (global or custom), any aggregate attribute | | Operator | Equals, Not equals, Greater than, Less than, Between, Contains (`ilike`), Is multiple of, In group, Is null, Is not null | | Value | A static input — or another attribute (for dynamic comparisons like birthday rules) | Multiple conditions combine with **AND** (all must match) or **OR** (any must match). ### THEN reward | Reward type | How points are calculated | Example | | --------------- | ---------------------------------------------- | ------------------------------------ | | **Flat points** | Fixed number regardless of transaction amount | 500 points for first purchase | | **Multiplier** | Transaction amount × multiplier | 2x = ₹5,000 transaction → 10,000 pts | | **For Every** | Fixed points for every N units of an attribute | 1 pt per ₹10 = ₹5,000 → 500 pts | ### Restrictions Add restrictions to control when and how much the rule fires: | Restriction | Effect | | ---------------------- | -------------------------------------------------------------------------- | | **Point Limit** | Cap earnings from this specific rule per transaction | | **Date Range** | Rule only fires between a start and end date — use for seasonal promotions | | **Product Codes** | Rule only fires for transactions with specific product codes | | **Calculation Timing** | Delay points posting (e.g., post after a 30-day return window) | ### A complete example **Rule Group: Base Earning** (no segment — all members) | Rule | IF | THEN | Restrictions | | ------------- | --------------------- | ------------------------ | ---------------------- | | Standard earn | Transaction Type = CR | 1 pt per ₹10 (For Every) | Point limit: 5,000 pts | **Rule Group: Platinum Benefits** (segment: Premium Card) | Rule | IF | THEN | Restrictions | | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------- | ---------------------- | | Weekend multiplier | Transaction Type = CR **AND** Transaction Date \[Day of Week] IN \[Saturday, Sunday] | 2x multiplier | — | | Birthday cashback | Transaction Date \[Day of Month] = Date of Birth \[Day of Month] **AND** Transaction Date \[Month of Year] = Date of Birth \[Month of Year] | 35% cashback | Point limit: 2,000 pts | | Online bonus | Channel = "Online" | 50 flat points | — | | Fuel exclusion | MCC Code = 5541 | 0 — rule does not fire | — | **Rule Group: New Member Welcome** (segment: New Members) | Rule | IF | THEN | Restrictions | | --------------- | ---------------------------------------- | --------------- | ------------ | | First purchase | Lifetime Transaction Count = 1 | 500 flat points | — | | Early milestone | Transaction Count (MTD) is multiple of 3 | 100 flat points | — | **Rule Group: Weekend Promotions** (no segment — all members) | Rule | IF | THEN | Restrictions | | ---------------- | ------------------------------------------- | ------------ | ------------------------------------------------- | | Every 20th order | Monthly Transaction Count is multiple of 20 | 25% cashback | Point limit: 500 pts, date range: campaign period | Rules within the same group all evaluate simultaneously against the same transaction. A Platinum cardholder transacting on a Saturday online earns the weekend multiplier **and** the online bonus **and** the base points — from different rule groups running in parallel. *** ## Advanced rule conditions ### "Is Multiple Of" operator The **Is Multiple Of** operator is available for aggregate integer attributes (e.g., Monthly Transaction Count, Lifetime Transaction Count). It triggers a reward every time the member's aggregate value reaches a multiple of the configured number. **Example:** | Condition | Reward | Meaning | | --------------------------------------------- | --------------- | ----------------------------------------------- | | `Monthly Transaction Count is multiple of 10` | 200 flat points | Every 10th transaction this month earns a bonus | | `Monthly Transaction Count is multiple of 20` | 25% cashback | Every 20th order earns enhanced cashback | Reversals are deducted from the aggregate count and can affect whether the multiple condition is met. ### Attribute-to-attribute date comparison Rule conditions can compare two **date-type attributes** against each other — not just a date attribute against a fixed value. **Example:** | Condition | Meaning | | ----------------------------------------------------------------------- | --------------------------------------------------------------------- | | `Transaction Date [Day of Month] equals Date of Birth [Day of Month]` | Matches transactions that occur on the member's birth date (any year) | | `Transaction Date [Month of Year] equals Date of Birth [Month of Year]` | Matches transactions in the member's birth month | **Rules and constraints:** * Self-comparison (an attribute compared against itself) is prevented * Comparisons between incompatible data types are blocked * Date-type fields are auto-locked in the comparison selector to enforce valid pairings Combining both conditions (Day of Month AND Month of Year) creates a birthday rule that matches only on the exact calendar day — useful for birthday cashback without hardcoding dates. Members with no value recorded for the comparison attribute (e.g., no Date of Birth) will not match the condition and will not receive the reward. ### Time picker for Transaction Date The **Transaction Date** attribute now includes a **time selector (HH:MM, 24-hour format)** alongside the date picker: * The default time is `00:00` if not explicitly set * The combined value is stored and evaluated as `MM/DD/YYYY HH:MM` * For the **Between** operator, each date boundary has its own independent time selection * Existing date-only rules are fully backward compatible — they are treated as `00:00` This allows time-of-day conditions such as "transactions placed between 18:00 and 23:59" or "early-morning bonus before 09:00". *** ## Phase 6 — Submit transactions With members enrolled and rules active, submit transactions to trigger rule evaluation. ### TXN file (batch) Upload via SFTP to `upload/TXN`. Required columns: ``` action | member_relation | name | transaction_type | amount | transaction_date | transaction_id | [+ any custom transaction attribute columns defined in Step 2b] ``` Every custom transaction attribute column must appear in every row (use empty string if not applicable for that row). A missing column causes a column count mismatch and rejects the entire file. ### API (real-time) Call the [Insert Transaction](/api-reference/transactions/insert-transaction) endpoint. The payload must include all 7 global attributes plus any custom transaction attributes defined in your program. ### What happens at evaluation time For each accepted transaction row, Loyalife: 1. Resolves the member from the Relation Reference 2. Identifies all active rule groups 3. For groups with a linked segment — checks whether the member is in that segment 4. Evaluates every rule's IF conditions against the transaction's attributes (both transaction-level and member-level) 5. Awards points from all matching rules across all qualifying groups simultaneously 6. Updates aggregate attributes (Monthly Spend Sum, Transaction Count, etc.) for the member 7. Re-evaluates tier qualification *** ## Phase 7 — Verify After submitting a test transaction, confirm the correct rules fired: 1. Go to **Members → \[search by Relation Reference] → Accrual Info** 2. Find the transaction by Transaction Id or date 3. The Accrual Info tab shows each rule that evaluated, whether it matched, and how many points it awarded 4. Cross-check against the rule conditions to confirm the evaluation logic is correct **Checklist before going live:** * [ ] All custom member attributes have the correct data type * [ ] All custom transaction attributes have the correct API / file key * [ ] At least one test member is enrolled via CPD or API * [ ] All rule groups are set to **Active** * [ ] Rules within each group are set to **Active** * [ ] A test TXN row submitted via API matched the expected rules * [ ] Accrual Info confirms correct points were awarded * [ ] Group-level caps are set to sensible values for your program volume *** ## Quick reference — where each piece is configured | What | Where in Loyalife | | ----------------------------- | ---------------------------------------- | | Product codes (picklist) | Configuration → Program Settings | | Custom member attributes | Members → Attributes | | Custom transaction attributes | Rule Engine → Attributes (settings icon) | | Member enrollment (file) | SFTP upload → `upload/CPD` | | Member enrollment (API) | Create Member Profile endpoint | | Rule groups | Rule Engine → Create Rule Group | | Segments (optional) | Engage → Segments → link to rule group | | Earning rules | Rule Engine → \[select group] → Add Rule | | Transaction submission (file) | SFTP upload → `upload/TXN` | | Transaction submission (API) | Insert Transaction endpoint | | Verify rule firing | Members → \[member] → Accrual Info | Every time an earning rule fires on a submitted transaction, one **Credit By Accrual** entry is written to the points ledger. These entries are visible in the member's transaction history and can be filtered in Transactional reports under [Reports & Analytics → Transaction Category → Credit By Accrual](/user-guides/reports/report-types#credit-by-accrual). # Data processing Source: https://help-loyalife.xoxoday.com/user-guides/rule-engine/data-processing Learn how Loyalife ingests transaction and member data via API or SFTP batch files, including TXN, CPD, BNS formats and validation rules. The Rule Engine processes data through two channels: real-time API calls and scheduled batch file uploads. Your choice depends on your source system's capabilities and the latency your loyalty program requires. ## Upload methods ### API integration (real-time) Connect your system directly to Loyalife's Transaction API to submit events as they occur. The Rule Engine evaluates and awards points immediately after each submission. **When to use API integration:** * Your program requires near-instant point updates after a purchase * Members expect to see their balance update right after a transaction * Your platform already has API capabilities See the [Insert Transaction API](/api-reference/transactions/insert-transaction) for the request format and field reference. ### Batch processing (file upload) Data accumulates over a defined period and is processed in bulk at scheduled intervals. Files are transferred via SFTP to the Loyalife server. **When to use batch processing:** * Your source system already exports transaction logs on a schedule (end of day, hourly, etc.) * Near-real-time updates are not required by your program * You are migrating a large historical transaction dataset ## SFTP file upload Request your program-specific SFTP credentials from your Loyalife administrator. These credentials are unique per program. SFTP access is VPN-restricted. Connect to your approved VPN before attempting the SFTP connection. Connect to the SFTP server and upload your file to the appropriate directory based on file type: | File type | Upload path | | --------------------------- | ------------ | | Transaction file (TXN) | `upload/TXN` | | Customer profile data (CPD) | `upload/CPD` | | Bonus file (BNS) | `upload/BNS` | | Card reference data (CRD) | `upload/CRD` | Processing begins automatically after upload. Check the **Logs** report in Reports & Analytics for upload status, processed record count, and any rejected rows. Files uploaded to the wrong directory are not processed. Always use the correct path for each file type. SFTP access requires an active VPN connection — uploads will fail if VPN is not connected. ## File types and formats Loyalife supports four file types for batch data ingestion. All files are CSV or pipe-delimited depending on program configuration. ### TXN — transaction file The TXN file submits purchase or activity transactions for points evaluation by the Rule Engine. The columns included in a TXN file are fully customisable — whatever fields the client's source system can export are defined as **global attributes** or **custom attributes** in Loyalife, and those values are ingested and stored against each transaction. Download the sample TXN file from the Rule Engine section in Loyalife before building your upload pipeline. It reflects the exact columns configured for your program. ### CPD — customer profile data file The CPD file updates member profile information — used when member data is managed in an external system and synced to Loyalife in bulk. The fields included are customisable per program: any member attributes the client wants to maintain in Loyalife are defined as global or custom attributes, and the CPD file carries those values in on each sync. ### BNS — bonus file The BNS file credits bonus points outside of the standard transaction-to-rule evaluation flow. It is used for manual bonus awards, promotional grants, or migration of historical balances. Like other file types, the columns are configurable and map to the attributes defined for your program. BNS entries bypass the Rule Engine — points are credited directly without evaluating IF/THEN conditions. Use BNS for direct awards only; use TXN files when you want the Rule Engine to calculate the correct point amount from a transaction. BNS file uploads post as **Credit By Bonus** entries on the member's ledger. If the BNS file is used for a balance migration or inbound transfer from an external programme, the entries may alternatively appear as **Credit Transfer**. Both are filterable in Transactional reports under [Reports & Analytics → Transaction Category](/user-guides/reports/report-types#transaction-categories). ### CRD — card reference data file The CRD file links cards and supplementary accounts to a primary member. It is used in banking programs where a single member account has multiple cards — for example, a primary cardholder with one or more supplementary cards for family members. CRD is relevant for programs where transactions arrive tagged with a card identifier rather than the primary member's Relation Reference. Loyalife uses the CRD mapping to resolve the correct member account when evaluating rules and posting points. Without a CRD entry, transactions submitted with an unrecognised card identifier are rejected. Once loaded, linked cards are visible in the member's profile under **Account Info → Linked Accounts & Cards**. Aggregate attributes (Monthly Spend Sum, Transaction Count, etc.) accumulate across all cards linked to the same primary account. ## Pre-processing layer For programs that receive data files from external systems (banks, ERP platforms, payment networks), Loyalife's pre-processing layer transforms files before ingestion. Pre-processing runs between SFTP upload and Rule Engine evaluation. Any fields a client wants to share — across any file type — are defined as **global attributes** or **custom attributes** in Loyalife. The pre-processing layer normalises the incoming file so those fields are correctly structured and can be pushed into Loyalife, where they are stored against the matching member or transaction attribute. This means the client's source file does not need to match Loyalife's internal format exactly — the pre-processing configuration handles the mapping. Typical transformations applied during pre-processing include date format normalisation, column merging, header stripping, and field trimming. The specific transformations are configured per program during onboarding based on the client's source file structure. ### Multi-program routing (BIN-based) For programs receiving a single file containing records for multiple loyalty programs (common in banking / card programs), the pre-processing layer can route records to the correct program using a **BIN** (Bank Identification Number) or equivalent routing key. Each routing key maps to exactly one program. Records with an unrecognised routing key are written to a reject file rather than ingested into any program. ## File validation Validation happens at two levels: the file as a whole, and then each row individually. ### File-level validation These checks run before any rows are processed. A failure here rejects the **entire file**: | Validation | Error | Fix | | ------------------------------------------ | ------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ | | File is not empty | `File should not be empty` | Confirm the export from your source system produced records | | File has at least one data row | `File must contain at least one record` | Remove header-only files; ensure data rows are present below the header | | Column headers match the expected template | `Invalid file format: Missing required headers` / `Invalid file format: Found unexpected headers` | Re-export using the sample file from the Rule Engine section; do not rename or reorder columns | | File is CSV or pipe-delimited | `Only CSV files are accepted` | Convert the file to CSV or the pipe-delimited format configured for your program | | File name does not exceed 50 characters | File is ignored by the processor | Shorten the filename before uploading | | File encoding is UTF-8 | File may process incorrectly or fail silently | Save the file as UTF-8 encoded; avoid opening and re-saving in Excel without specifying encoding | ### Row-level validation Each row is validated independently. A failed row is rejected and logged; all other valid rows continue processing: | Validation | Outcome on failure | | -------------------------------------------------------------------------- | --------------------------- | | All mandatory fields present | Row rejected | | Relation Reference exists in Loyalife | Row rejected | | Transaction date is a valid format (`YYYY-MM-DD` or `YYYY-MM-DD HH:MM:SS`) | Row rejected | | Amount is a valid number (not empty, not text) | Row rejected | | Points value is a valid non-zero number (BNS files) | Row rejected | | Currency type is a recognised value | Row rejected | | Duplicate transaction reference | Row skipped (deduplication) | | Column count matches expected number of columns | Row rejected | Rejected rows do not prevent other valid rows from processing. The rejection count and per-row error messages appear in the Logs report. ### Complete error reference **File-level errors** (entire file rejected): | Error message | Cause | Fix | | -------------------------------------------------------- | ------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | | `Invalid file format: Missing required headers` | One or more expected column headers are absent | Use the sample file template; do not remove or rename columns | | `Invalid file format: Found unexpected headers` | File has extra columns not in the template | Remove any added columns; match the template exactly | | `Invalid file format: Please use the sample file format` | General header mismatch | Re-download and re-use the sample file | | `File should not be empty` | File contains no data | Confirm the source export produced records | | `Column count mismatch` | A row has more or fewer columns than the header defines | Check for stray commas or missing delimiters; wrap text fields containing commas in double quotes | | `Only CSV files are accepted` | File is not a supported format | Convert to CSV or pipe-delimited format | **Row-level errors** (individual row rejected): | Error message | Cause | Fix | | -------------------------------------------------- | ----------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ | | `Member not found` | Relation Reference in the row does not match any enrolled member | Verify member IDs against the Members list; re-export from source if out of sync | | `Missing mandatory field` | A required column is empty for this row | Fill in the missing value or remove the row | | `Invalid date format` | Transaction date is not in `YYYY-MM-DD` or `YYYY-MM-DD HH:MM:SS` format | Correct the date column; confirm pre-processing is applied if source uses a different format | | `Date & Time format should be YYYY-MM-DD HH:MM:SS` | Combined timestamp column has incorrect format | Ensure date and time columns are merged correctly; check pre-processing configuration | | `Amount must be a valid number` | Transaction amount is empty, contains text, or is non-numeric | Clean the amount column; remove currency symbols, spaces, or commas used as thousands separators | | `Points must be a valid number` | Points value in a BNS row is empty or non-numeric | Correct the bonus amount column | | `Points cannot be zero` | BNS row has a zero bonus amount | Remove zero-value rows or correct the amount | | `Invalid currency type` | `CURRENCY_TYPE` value is not `MOKAFAA` or `CASHBACK` | Use only the accepted currency type values for your program | | `Duplicate transaction reference` | A transaction with this reference was already processed | Remove duplicate rows; use unique reference IDs per transaction | | `Comma in text field` | A CSV field contains an unquoted comma | Wrap fields containing commas in double quotes: `"Test transaction, bonus"` | **Processing errors** (file fails during backend processing): | Error message | Cause | Fix | | -------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- | | `Error in processing file` | A technical error occurred during file processing | Retry the upload; if the error persists, contact your Loyalife administrator | | `File processing failed completely due to technical error in the database` | Database-level failure during ingestion | Contact your Loyalife administrator — this requires investigation on the backend | | `The log file is no longer available for download` | The error log has been automatically deleted per the program's report retention settings | Download error logs promptly after upload; check program retention period settings | ## Rule evaluation on batch files After validation, each accepted row is evaluated against all active rule groups, following the same logic as real-time API transactions: 1. Member's segment membership is checked against each rule group's linked segment 2. IF conditions are evaluated against the transaction's attributes 3. Matching rules apply their THEN reward 4. Points are posted to the member's account 5. Tier re-evaluation is triggered for the member ## Error file delivery (SFTP return) After processing, Loyalife can automatically deliver the **error file** (rows that failed validation) back to the client's SFTP server. This enables fully automated pipelines where the client system receives rejected rows without accessing the Loyalife UI. This feature is configured per program and supports selective file types (e.g., only CPD and TXN error files, not BNS). Error files are placed in the client's designated inbound SFTP path. The file naming convention mirrors the input file with a suffix indicating it is a rejection report. Error file delivery to client SFTP is enabled by the Loyalife operations team during program setup. It is not available as a self-service toggle in the admin UI. ## Monitoring uploads Go to **Reports & Analytics → Data Exports → Logs** to see: | Column | Description | | ---------------- | ------------------------------ | | Upload timestamp | When the file was received | | File name | The original filename | | Total rows | Total records in the file | | Processed | Successfully evaluated records | | Rejected | Rows that failed validation | | Status | Completed, Processing, Failed | Click any upload entry to see per-row rejection details, including the exact error message for each rejected row. ## Troubleshooting **File uploaded but no points were awarded.** * Check the Logs report for the file's processing status. * Review the rejection count — if all rows were rejected, look at the error messages. * Verify Relation References in the file match enrolled members in Loyalife. * Confirm active rule groups exist for the members and transaction types in the file. **SFTP connection refused.** * Confirm you are connected to the approved VPN. * Verify credentials are correct and have not expired. * Contact your Loyalife administrator to check SFTP server status. **Processing shows 0 records processed.** * Verify the file was uploaded to the correct directory for its type (`upload/TXN`, `upload/CPD`, `upload/BNS`, `upload/CRD`). * Check file encoding — Loyalife expects UTF-8 encoded files. * Ensure the first row is the header row and that column names match the configured template exactly. **Not receiving upload status notifications.** * Loyalife can send email notifications when a CPD, TXN, or BNS file finishes processing. The Super Admin is always notified. Additional email addresses can be added under Program Settings → Notifications. Contact your Loyalife administrator to configure this. # Rule Engine overview Source: https://help-loyalife.xoxoday.com/user-guides/rule-engine/overview Explore how Loyalife's Rule Engine builds no-code earning rules using IF/THEN conditions, attributes, restrictions, and reward types. The Rule Engine is the core of your loyalty program's incentive structure. It lets you create conditions-based rules — "if a transaction meets these criteria, apply this reward" — without any code. Rules support simple flat-rate earning, tiered multipliers, milestone bonuses, birthday cashback, and time-targeted promotions. ## How it works When a transaction arrives (via API or file upload), Loyalife evaluates all active rule groups whose linked segment includes the transacting member. Matching rules determine how many points, what cashback percentage, or what bonus applies. Results are posted to the member's account immediately. **Example — retail loyalty program:** * Earn 2 points per ₹1 spent at any time * Earn an additional 1% cashback on transactions above ₹5,000 * Earn 500 bonus points on the member's birthday month * Earn a 25% cashback on every 20th order in a calendar month Each is a separate rule inside the same rule group. All evaluate simultaneously for each transaction. Rule Engine screen with rule groups shown as tabs at the top and individual rules listed in sequence order within the selected group, with toggle controls to activate or deactivate each rule ## Core components Data variables that carry information about transactions and members. Attributes are the inputs that rules evaluate. Named containers that hold related rules. Can be linked to a specific segment so rules only apply to a targeted audience. IF/THEN logic statements: if conditions are met, award the defined reward. Each rule has conditions, a reward type, and optional limits. ## Building an earning rule ### IF conditions Each condition has three parts: | Part | Description | | ------------- | ------------------------------------------------------------------------- | | **Attribute** | The data point to check (e.g., Transaction Amount, MCC, Transaction Date) | | **Operator** | How to compare (equals, greater than, contains, between, is multiple of) | | **Value** | A static threshold, or another member attribute for dynamic comparisons | Multiple conditions combine with **AND** (all must be true) or **OR** (any must be true). Every rule condition evaluates a **combination of transaction attributes and member attributes** — what happened in the transaction, and who the member is. This is what makes the Rule Engine powerful: a single rule can simultaneously check "was the transaction amount above ₹5,000?" (transaction attribute) and "is the member in the Gold tier?" (member attribute) and "has the member transacted more than 10 times this month?" (aggregate attribute). **Supported attribute categories:** | Category | Source | Examples | | --------------------------------- | --------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- | | **Transaction attributes** | Submitted with each transaction via API or TXN file | Transaction Amount, Transaction Date, Product Code, Sub Product Code, Transaction Type, Relation Reference, Transaction Id | | **Custom transaction attributes** | Defined by you in Rule Engine → Attributes | Merchant Name, MCC Code, Channel, Store ID, any program-specific transaction field | | **Member (global) attributes** | Built-in member profile fields | Date of Birth, Gender, Status, Preferred Language | | **Member (custom) attributes** | Defined by you in Members → Attributes | Occupation, region, card type, any program-specific member field | | **Aggregate attributes** | Computed from transaction history | Monthly Spend Sum, Transaction Count (MTD/YTD), Average Transaction Value | ### Operators | Operator | Applies to | Description | | ------------------------ | -------------- | ----------------------------------------------------- | | Equals / Not Equals | All types | Exact match or exclusion | | Greater Than / Less Than | Numbers, Dates | Threshold comparison | | Between | Numbers, Dates | Inclusive range check | | Contains | Text | Substring match (e.g., merchant name contains "Fuel") | | **Is Multiple Of** | Numbers | Matches every Nth value — used for milestone rewards | ### Date and time conditions The Transaction Date attribute supports **combined date and time** values. The date picker opens with a calendar plus an embedded time selector (HH:MM, 24-hour format) below the grid. | Picker element | Behavior | | --------------------- | -------------------------------------------------- | | Calendar | Select the date as usual | | Time selector (HH:MM) | Hour range 00–23, minute range 00–59 | | Default time | 00:00 (midnight) | | Today button | Sets current date + current time | | Apply button | Confirms and closes the picker | | Combined display | Shows as `MM/DD/YYYY HH:MM` in the condition field | For the **between** operator, both start and end pickers include their own time selectors. Existing rules with date-only values continue to work as-is — they are treated as 00:00 by default. **Example use cases:** | Rule condition | Value entered | Meaning | | ------------------------ | ----------------------------------- | ---------------------------------------- | | Transaction Date > | 04/22/2026 18:00 | Only transactions after 6 PM on April 22 | | Transaction Date between | 04/01/2026 00:00 → 04/30/2026 23:59 | All of April | | Transaction Date = | 04/22/2026 14:30 | Exactly at 2:30 PM on April 22 | ### Dynamic attribute comparisons — birthday and anniversary rules Instead of comparing an attribute to a fixed value, you can compare it to another **member attribute**. This enables rules like birthday cashback or card anniversary bonuses. **Birthday cashback example:** ``` Condition 1: Transaction Date [Date of Month] Equals Date of Birth [Date of Month] Condition 2: Transaction Date [Month of Year] Equals Date of Birth [Month of Year] THEN: 35% cashback ``` **Constraints for dynamic comparisons:** | Constraint | Rule | | --------------------- | ---------------------------------------------------------------------------------------- | | No self-comparison | An attribute cannot compare to itself | | Type compatibility | Left and right must be the same data type (Date ↔ Date, Number ↔ Number) | | Date type lock | If the left side uses `[Date of Month]`, the right side auto-locks to `[Date of Month]` | | Operator restrictions | `Contains` and `Is Multiple Of` are not available for attribute-to-attribute comparisons | **Edge cases for birthday rules:** | Scenario | Behavior | | ----------------------------------------------------- | ------------------------------------------------------- | | Date of Birth not set in member profile | Condition evaluates to false — no birthday reward | | Member born on Feb 29 | No birthday reward in non-leap years | | Profile DOB updated mid-month (reward already issued) | Next reward on the new date, following year | | Supplementary card transaction | Uses the DOB of the primary account linked to that card | ### Milestone rewards (Is Multiple Of) The **Is Multiple Of** operator fires a rule every time an aggregate count or sum hits a multiple of your configured value. The current transaction is included in the aggregate before evaluation. Reversals and refunds adjust the aggregate automatically. **Example — reward every 20th order per month:** ``` Attribute: Monthly Order Count Operator: Is Multiple Of Value: 20 Reward: 25% cashback (capped at ₹500 per transaction) ``` This fires on the 20th, 40th, 60th order, and so on. An implicit `Count > 0` guard is added automatically when you use **Is Multiple Of** to prevent zero from incorrectly matching (since 0 is technically a multiple of any number). ### THEN reward | Reward type | Internal name | Description | | --------------- | :--------------: | ----------------------------------------------------------------------------------------------------------- | | **Flat Points** | `flat` | A fixed number of points regardless of transaction amount | | **Multiplier** | `mutiple` | Multiplies the transaction amount (or base earning) by the configured factor to calculate points | | **For Every** | `attributeValue` | Awards a fixed number of points for every N units of an attribute value (e.g., 1 point for every ₹10 spent) | **Value type for the THEN condition:** | Value type | Description | | ------------------- | -------------------------------------------------------------------------------- | | **Static value** | A fixed number configured in the rule | | **Match attribute** | The value is drawn from a member attribute at the time of transaction evaluation | ### Restrictions Each earning rule can carry one or more restrictions that limit *when* and *how much* the rule fires. Add restrictions from the **Restrictions** section of the rule builder. | Restriction type | What it does | | ------------------------------- | ------------------------------------------------------------------------------------------------------------- | | **Point Limit (MaximumPoints)** | Sets a hard cap on the maximum points a single transaction can earn from this rule | | **Date Range** | Restricts the rule to only fire within a specific start–end date window | | **Calculation Timing** | Controls when points are posted after a qualifying transaction (e.g., immediately vs. after a holding period) | | **Product Codes** | Restricts the rule to only fire for transactions with specific product codes | | **Sub Product Codes** | Further narrows to specific sub-product codes within a product category | **Combining restrictions:** Multiple restrictions are evaluated together with AND logic — a transaction must satisfy all active restrictions for the rule to fire. For example, a rule restricted to a date range AND specific product codes will only fire for qualifying products within that time window. Restrictions layer on top of IF conditions, not instead of them. A transaction must first pass all IF conditions, then pass all active restrictions, before the THEN reward is applied. ### Limits and caps | Level | Limit type | Description | | ----- | --------------- | ------------------------------------------ | | Rule | Per transaction | Maximum earning per single transaction | | Rule | Velocity | Maximum qualifying transactions per period | | Group | Daily | Maximum group earning per member per day | | Group | Monthly | Maximum group earning per member per month | | Group | Lifetime | Maximum group earning per member ever | ## Activating and deactivating rules Changes to rule status (active/inactive) take effect immediately for new transactions. They do not retroactively apply or reverse points already awarded. ## Troubleshooting **A rule is not firing on expected transactions.** * Confirm the rule group is set to Active. * Check whether the group has a linked segment — the transacting member must be in that segment. * Review all condition operators and values carefully, especially date formats and time values. * Check whether a group-level cap for this member has already been reached. **A member is earning on transactions that should be excluded.** * Identify all active rule groups with no segment restriction — they apply to every member. * Look for overlapping conditions that inadvertently match. **Birthday rule is not firing.** * Confirm the member's Date of Birth is populated in their profile. * Members born on February 29 receive no birthday reward in non-leap years. * If the DOB was updated mid-month after the reward was already issued, the new date takes effect the following year. # Rule groups Source: https://help-loyalife.xoxoday.com/user-guides/rule-engine/rule-groups Learn how rule groups control which members earning rules apply to, set earning caps, and organize campaigns in Loyalife's Rule Engine. Rule groups are the **organisational backbone of the Rule Engine**. They are not just folders — they are the mechanism that determines *which members* a set of rules applies to and *how much* those members can earn in aggregate. Every earning rule must belong to a rule group. Rule Engine — Manage Rule Groups screen showing rule groups displayed as cards in a grid, each card listing the group name, linked segment, status badge (Active/Inactive), and rule count ## Why rule groups matter Without rule groups, all rules would apply to every member in the program. Rule groups solve three problems that a flat rule list cannot: | Problem | How rule groups solve it | | --------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | | **Different earning rates for different audiences** | Link a rule group to a segment — only members in that segment earn from those rules | | **Preventing over-earning across multiple rules** | Group-level caps limit total earning per member across all rules in the group, per day, month, or lifetime | | **Organising complexity** | Separate rule groups for base earning, promotions, partner schemes, and seasonal offers — each independently managed and togglable | ## How rule group evaluation works When a transaction arrives, Loyalife: 1. Identifies all **active** rule groups 2. For each group with a linked segment, checks whether the transacting member is in that segment 3. Evaluates every rule inside each qualifying group 4. Awards rewards from all matching rules across all qualifying groups **simultaneously** A member can earn from multiple rule groups in a single transaction. For example, a Gold tier member can earn base points from an "All Members" group and a tier bonus from a "Gold Members" group at the same time — as long as both groups are active and the member is in each group's segment. ## Rule group properties | Property | Description | | ------------------ | ----------------------------------------------------------------------------------------- | | **Name** | Internal label shown in reports, audit logs, and the maker-checker queue | | **Description** | Optional explanation of the group's purpose | | **Linked Segment** | If set, rules only apply to members in this segment. Leave unset to apply to all members. | | **Point Limit** | Maximum points a member can earn from this group per transaction | | **Daily Cap** | Maximum points per member per day across all rules in this group | | **Monthly Cap** | Maximum points per member per calendar month | | **Lifetime Cap** | Maximum points per member ever — once reached, no further earning from this group | | **Status** | Active or Inactive — toggling pauses all rules in the group instantly | Group-level caps are distinct from rule-level caps. A rule-level cap limits earning per transaction for that specific rule. A group-level cap limits total earning across all rules in the group combined, over a time period. ## Designing rule groups A well-designed program typically uses several rule groups with clearly separated purposes: ``` Rule Group: Base Earning (no segment — applies to all members) └── Rule: 1 point per ₹1 spent Rule Group: Gold Member Promotions (segment: Gold tier) └── Rule: 2x multiplier on weekends └── Rule: 500 bonus points on birthday Rule Group: New Member Welcome (segment: Enrolled in last 30 days) └── Rule: 3x points on first 3 transactions Rule Group: Partner Scheme – Brand X (segment: Brand X customers) └── Rule: 5 points per ₹1 at Brand X outlets ``` Each group is managed independently. Pausing **Gold Member Promotions** has no effect on **Base Earning**. Enabling a new seasonal group for a limited campaign doesn't require touching existing groups. ## Creating a rule group Select **Rule Engine** from the left sidebar. Enter a name and optional description. Choose a linked segment if the group should only apply to a specific audience. Set point limit, daily cap, monthly cap, or lifetime cap if you want to constrain total earning from this group. Save the group, then add individual earning rules to it using the rule builder. Update Rule Group modal showing Name field, Description field, Point Limit and Daily Cap inputs, Monthly Cap and Lifetime Cap fields, and a Target Segment dropdown for linking the group to a member segment ## Creating a rule group from the Segment flow You can also create a rule group directly while building a segment. Use the **+ Create New Rule Group** button inside the segment creation form. The group is automatically linked to the parent segment. After creation, go to Rule Engine to add earning rules to the group. ## Activating and deactivating Toggling a rule group between Active and Inactive takes effect immediately for new transactions. It does not retroactively apply or reverse points already awarded from rules in that group. When the Maker-Checker workflow is enabled for the Rule Engine, activating or deactivating a rule group requires approval before taking effect. # Transaction types Source: https://help-loyalife.xoxoday.com/user-guides/rule-engine/transaction-types Full reference for Loyalife's Transaction Type (TT) and Loyalty Transaction Type (LTT) codes used to classify every credit and debit event. Every transaction in Loyalife carries two numeric classifiers that determine how it is processed, displayed, and reported. | Field | Full name | What it identifies | | ------- | ------------------------ | ------------------------------------------------------------- | | **TT** | Transaction Type | The direction of the transaction — credit, debit, or reversal | | **LTT** | Loyalty Transaction Type | The specific activity or reason within that direction | ## TT values | TT | Direction | Description | | ----- | -------------- | ------------------------------------------------------------ | | **1** | Credit | Points accrual and credit-side reversals | | **2** | Debit | Redemptions, expiry, chargebacks, and debit-side adjustments | | **4** | Reversal | Reversal of redemption transactions | | **5** | Credit Pending | Points credited but held in pending state before posting | ## Complete LTT reference The table below lists all 54 Loyalty Transaction Type codes, their names, and typical usage context. | LTT | Name | Typical direction | Description | | --- | ---------------------------- | :---------------: | --------------------------------------------------------------------------------------------------------- | | 1 | Spend | Credit / Debit | Standard points accrual on purchase spend, or debit on spend-based redemption | | 2 | Bonus | Credit / Debit | Bonus point grant — covers referral bonuses, campaign bonuses, tier bonuses, and manual bonus adjustments | | 3 | Partner | Credit | Points earned through a partner programme (airline, hotel, co-brand partner) | | 4 | Purchase | Credit / Debit | Purchase-linked accrual or debit; used for manual purchase adjustments | | 5 | Air | Credit / Debit | Airline mileage accrual or debit | | 6 | Hotel | Credit / Debit | Hotel stay accrual or debit | | 7 | Car | Credit / Debit | Car rental accrual or debit | | 8 | Reversal | Credit | Credit-side reversal — restores points that were debited | | 9 | None | — | Null/invalid loyalty type; transactions with LTT 9 do not post | | 10 | CreditTransfer | Credit | Points transferred in from an external source or credit transfer event | | 11 | Merchant | Debit | Merchant-specific points adjustment or debit | | 12 | POS | Credit | Points earned from a point-of-sale terminal transaction | | 13 | Insurance | Credit | Points earned on insurance premium payment | | 14 | CashBack | Credit | Cashback credited as points | | 15 | FeeWaiver | Credit | Points awarded as a fee waiver or compensation | | 16 | PriorityPass | Credit | Points earned through priority pass or lounge access events | | 17 | InfiVoucher | Credit | Points awarded via InfiVoucher promotion | | 18 | Expiry | Debit | Points expired or debited on account closure | | 19 | Charity | Debit | Points donated to a charity redemption | | 20 | Campaign | Credit | Points awarded by a campaign rule | | 21 | Miscellaneous | Debit | Miscellaneous adjustment debit (chargebacks, corrections) | | 22 | BillPayment | Credit | Points earned on utility or bill payment | | 23 | AirHotel | Credit | Combined air + hotel package accrual | | 24 | Canceled | Debit | Points reversed on order cancellation | | 25 | Online | Credit | Points earned on online channel purchases | | 26 | Packages | Credit | Points earned on bundled package purchases | | 27 | WebPos | Credit | Points earned through web-based POS terminal | | 28 | Lounge | Credit | Points earned on lounge access events | | 29 | Loan | Credit | Points earned on loan disbursement or repayment | | 30 | GiftCard | Debit | Gift card redemption or voucher issuance (points value may be zero for voucher events) | | 31 | Topup | Credit | Points earned on wallet top-up | | 32 | Game | Credit | Points earned from in-app game activity | | 33 | RegistrationReward | Credit | Welcome or registration bonus awarded on enrolment | | 34 | ReferralReward | Credit | Points awarded to a referrer when a referred member qualifies | | 35 | AccountOpening | Credit | Points earned for opening a new account | | 36 | ChildMarketplaceRewardParent | Credit | Parent account points credit from a child marketplace reward event | | 37 | ChildMarketplaceRewardChild | Credit | Child account points credit from a marketplace reward event | | 38 | AccountOpeningParent | Credit | Parent account points on child account opening | | 39 | AccountOpeningChild | Credit | Child account points on account opening | | 40 | FirstWalletRegistration | Credit | First-time wallet registration reward | | 41 | FirstBankAccountTopUp | Credit | Points awarded on the first bank account top-up | | 42 | ChildFirstTaskParent | Credit | Parent reward when a child completes their first task | | 43 | ChildBirthdayGift | Credit | Birthday gift points for a child account | | 44 | TeenBirthdayGift | Credit | Birthday gift points for a teen account | | 45 | FamilyFriendLinking | Credit | Points awarded for linking a family member or friend | | 46 | TwentyFourMonthsActive | Credit | Loyalty reward for 24 months of continuous activity | | 47 | DebitTransfer | Debit | Points transferred out to an external destination | | 48 | EComm | Credit | Points earned from e-commerce channel transactions | | 49 | PeerToPeerTransfer | Credit / Debit | Points transferred between members — always created as a matching debit/credit pair | | 50 | AcuralHousekeeping | Credit | Internal housekeeping credit used in batch accrual processing | | 51 | ExpiryHousekeeping | Debit | Internal housekeeping debit used in batch expiry processing | | 53 | SportsEvents | Debit | Redemption for sports event tickets | | 54 | RewardPoint | Debit | Redemption via reward points catalogue | LTT values 3, 9, 12–17, 19–29, 31–48 are available in the system but may not appear in every program. Which LTT codes are active depends on the transaction types configured during program onboarding. ## Grouped quick reference ### Accrual (TT = 1) | LTT | Name | | --- | ------------------------------- | | 1 | Spend | | 2 | Bonus | | 3 | Partner | | 4 | Purchase | | 5 | Air | | 6 | Hotel | | 7 | Car | | 8 | Reversal | | 10 | CreditTransfer | | 12 | POS | | 13 | Insurance | | 14 | CashBack | | 15 | FeeWaiver | | 16 | PriorityPass | | 17 | InfiVoucher | | 20 | Campaign | | 22 | BillPayment | | 23 | AirHotel | | 25 | Online | | 26 | Packages | | 27 | WebPos | | 28 | Lounge | | 29 | Loan | | 31 | Topup | | 32 | Game | | 33 | RegistrationReward | | 34 | ReferralReward | | 35 | AccountOpening | | 36 | ChildMarketplaceRewardParent | | 37 | ChildMarketplaceRewardChild | | 38 | AccountOpeningParent | | 39 | AccountOpeningChild | | 40 | FirstWalletRegistration | | 41 | FirstBankAccountTopUp | | 42 | ChildFirstTaskParent | | 43 | ChildBirthdayGift | | 44 | TeenBirthdayGift | | 45 | FamilyFriendLinking | | 46 | TwentyFourMonthsActive | | 48 | EComm | | 49 | PeerToPeerTransfer *(receiver)* | | 50 | AcuralHousekeeping | ### Redemption & debit (TT = 2) | LTT | Name | | --- | ----------------------------- | | 1 | Spend | | 2 | Bonus | | 4 | Purchase | | 5 | Air | | 6 | Hotel | | 7 | Car | | 11 | Merchant | | 14 | CashBack | | 18 | Expiry | | 19 | Charity | | 21 | Miscellaneous | | 24 | Canceled | | 30 | GiftCard | | 47 | DebitTransfer | | 49 | PeerToPeerTransfer *(sender)* | | 51 | ExpiryHousekeeping | | 53 | SportsEvents | | 54 | RewardPoint | ### Reversal (TT = 4) | LTT | Name | | --- | ---------------------------- | | 9 | None *(redemption reversal)* | ## Special patterns ### Peer-to-peer transfers PeerToPeerTransfer (LTT 49) always generates a **matched pair** of entries: | Side | TT | LTT | Effect | | -------- | -- | --- | --------------------------------------- | | Sender | 2 | 49 | Points debited from the sending member | | Receiver | 1 | 49 | Points credited to the receiving member | Both entries are created simultaneously. Reports can filter by TT to view only credits or only debits. ### Manual adjustments Manual adjustment narrations share LTT codes with standard accrual/debit types but can appear as either TT 1 (credit) or TT 2 (debit) depending on the adjustment direction: | Narration | Credit (TT 1) LTT | Debit (TT 2) LTT | | ---------------------------------------- | :---------------: | :--------------: | | Manual Adjustment – Bonus Points | 2 | 2 | | Manual Adjustment – Purchase Points | 4 | 4 | | Manual Adjustment – Air Points | 5 | 5 | | Manual Adjustment – Hotel Points | 6 | 6 | | Manual Adjustment – Car Points | 7 | 7 | | Manual Adjustment – Merchant Points | 11 | 11 | | Manual Adjustment – Miscellaneous Points | — | 21 | ### Shared LTT codes Some LTT values are reused across different narrations — the **Narration** field in transaction history and reports is what distinguishes the source event: | LTT | Shared by | | --- | ------------------------------------------------------------------------------------------ | | 2 | Referral Bonus, Tier Bonus, Campaign Bonus, Bonus Points, Manual Adjustment – Bonus Points | | 18 | Expired Points, Closed Account | | 30 | Redemption GiftCard, Voucher Issuance *(voucher issuance has zero points value)* | ### Voucher issuance Voucher Issuance uses TT 2 / LTT 30 — the same code as Redemption GiftCard — but the points value is always **zero**. A voucher issuance records the event without debiting the member's balance. # Configure tiers Source: https://help-loyalife.xoxoday.com/user-guides/tiers/configure-tiers Step-by-step guide to enabling Loyalife tiers: choose an assessment method, set qualification criteria, and configure your base tier. Tiers are disabled by default. You must explicitly enable them and configure the assessment approach before members can be assigned to tier levels. This page walks through each configuration step. ## Step 1: Enable tiers Navigate to **Tiers** in the left sidebar and click **Enable Tiers**. Confirm the prompt. The Tiers module is now active and will begin evaluating member qualification on the next scheduled assessment run. ## Step 2: Choose an assessment method Select how Loyalife evaluates and updates member tier status: ### Automated assessment Loyalife runs tier evaluation daily and automatically moves members between tiers based on their qualifying activity. Choose a qualifying time window: | Option | How it works | | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Lifetime basis** | Counts all points ever earned since enrollment. Members who reach a tier never lose it due to inactivity (unless you set a retention period). Best for programs that want to reward loyalty accumulated over years. | | **Rolling period** | Counts only points earned within a recent window (e.g., past 12 months). Members must maintain activity to keep their tier. Best for programs that want to reward ongoing engagement rather than past activity. | ### Manual assessment Tiers are managed externally through: | Method | Use case | | --------------------- | ------------------------------------------------------------------------------------------------------------------------ | | **Tier APIs** | Your platform calls the Tier API to set a member's tier — useful when tier logic is complex and lives in your own system | | **Rule Engine flows** | Campaign-driven tier changes based on custom Rule Engine conditions — for programs with event-triggered tier assignments | Tier Assessment Settings screen showing Assessment Process section with Automated and Manual radio options, Lifetime and Rolling Year basis choices, Retention Period toggle with days input, Aggregate Attribute selector, and Qualification Method options for Points only, Aggregated Attributes only, or Both ## Step 3: Set the qualification method Choose what data determines tier eligibility: | Method | Qualifying criteria | | ------------------------------ | --------------------------------------------------------------------------------------------------------------------- | | **Points only** | Member's accumulated points (lifetime or rolling) against the tier threshold | | **Aggregated attributes only** | Custom aggregate metrics defined in the Rule Engine — for example, total spend, transaction count, or account balance | | **Both** | Member must satisfy both points AND attribute thresholds simultaneously | Aggregated attributes are defined in the Rule Engine's Attributes Manager. Any aggregate attribute you create automatically becomes available as a tier qualification criterion. ### Changing the qualification method If you need to switch the qualification method after the program has launched (for example, from Points only to Both), the system will: 1. Ask you to confirm the change. 2. Request any additional data required for the new method. 3. Discard the data stored for the previous method. Changing the qualification method affects all existing tier assignments across your entire member base. Test this change carefully in a non-production environment before applying it to a live program. ## Step 4: Configure the base tier The base tier is the entry level that all members start in. It cannot be deleted after creation. Tier settings form showing Tier Icon upload, Tier Name field, Set Criteria section with Points Milestone input, Add Benefits button, and a Tier Member Distribution chart on the right Upload an image (square format recommended) that visually represents this tier in member-facing interfaces. This icon appears in the member app, on tier upgrade notifications, and in communications. Enter a name that your members will recognize — e.g., Member, Bronze, Silver, Classic. This label appears across the member app, admin portal, and all communications. Define the minimum threshold for the base tier. Typically 0 for the base tier — all members qualify automatically. Choose what members in the base tier receive: | Benefit type | Description | | ---------------- | ---------------------------------------------------------------------------------------------- | | Bonus points | Fixed points awarded when a member first reaches this tier's milestone | | Point multiplier | Percentage increase on all future point earnings (e.g., 1.0× for the base tier means no bonus) | | Custom benefits | Non-point rewards — vouchers, services, exclusive access — configured externally | The multiplier for the base tier defaults to 1.0× and the milestone defaults to 0. These values are typically left at default for the base tier. Upper tiers have fully editable milestone thresholds and multipliers. ## Step 5: Configure tier retention (optional) After the base tier is created, you can configure the **Tier Retention Period** — the number of days a member keeps their tier status after dropping below the qualifying threshold. Go to **Tiers → Update Settings** to enable and set the retention period. See [Manage tiers](/user-guides/tiers/manage-tiers) for details. ## After setup Once the base tier is configured, add additional tier levels from **Tiers → Add a new tier**. See [Manage tiers](/user-guides/tiers/manage-tiers) for the full workflow. If you configure entry-bonus points on a tier, those points are posted as **Credit By Bonus** entries when a member achieves that tier. You can track tier bonus distributions in Transactional reports by filtering on [Credit By Bonus](/user-guides/reports/report-types#credit-by-bonus) and checking the Narration column. # Manage tiers Source: https://help-loyalife.xoxoday.com/user-guides/tiers/manage-tiers Add, edit, and delete loyalty tiers in Loyalife. Learn tier retention settings, evaluation schedules, and how to troubleshoot upgrades. Once your base tier is configured, add additional levels above it to create a full tier hierarchy — for example, Silver → Gold → Platinum → Diamond. Each tier has its own milestone threshold, earning multiplier, and upgrade benefit. Manage Tiers screen listing five configured tier levels — Bronze, Silver, Platinum, Gold, and a new tier — with columns for Tier Name, Members Count, Multiplier, Criteria (points threshold), Welcome Bonus, and Actions menu ## Adding a new tier Navigate to **Tiers → Add a new tier** and fill in the required fields: | Field | Required | Description | | ------------------- | -------- | -------------------------------------------------------------------- | | Tier icon | Yes | Image representing this tier in member-facing interfaces | | Tier name | Yes | Unique label — e.g., Gold, Platinum, Diamond | | Milestone | Yes | Points threshold or attribute value required to reach this tier | | Benefits | Optional | Reward granted when a member first achieves this tier | | Milestone attribute | Optional | A custom aggregate attribute for advanced qualification calculations | Add New Tier form showing Tier Icon upload, Tier Name field, Set Criteria section with Points Milestone input and Milestone Attribute selector, Add Benefits button, and a Tier Member Distribution pie chart on the right showing current member spread across tiers Benefits are awarded only when a member **first achieves** a tier milestone. Members already in the tier when you configure or edit the benefit do not receive it retroactively. ## Tier hierarchy example | Tier | Milestone (lifetime points) | Multiplier | Upgrade benefit | | ------------- | --------------------------- | ---------- | ------------------------------------ | | Silver (base) | 0 | 1.0× | — | | Gold | 5,000 | 1.5× | 200 bonus points | | Platinum | 15,000 | 2.0× | 500 bonus points + exclusive voucher | | Diamond | 50,000 | 3.0× | Premium access benefit | ## Configuring tier retention The **Tier Retention Period** lets you give members a grace period before being downgraded when their qualifying activity drops below a tier's threshold. **Accessing tier retention settings:** Go to **Tiers → Update Settings**. | Setting | Description | | ----------------------- | --------------------------------------------------------------------- | | Enable/Disable toggle | Turn retention on or off for all tiers | | Retention period (days) | How long a member keeps their tier after dropping below the threshold | **Example:** With a 365-day retention period, a member who earned Gold by June 2025 retains Gold status until June 2026 — even if they make no further transactions. All changes to the Tier Retention Period — both toggling the setting and changing the number of days — are recorded in the Audit Trail with the before and after values. ## Editing a tier 1. Go to **Tiers**. 2. Select the tier you want to edit. 3. Click **Menu → Edit**. 4. Update the name, milestone, benefits, or multiplier as needed. 5. Save. Changes to milestone thresholds apply on the next tier evaluation run (daily schedule). Members may take up to 24 hours to move into or out of the tier after a threshold change. ## Deleting a tier 1. Go to **Tiers**. 2. Select the tier to delete. 3. Click **Menu → Delete**. 4. Confirm the deletion. Deleting a tier **automatically demotes all current members** in that tier to the next lower tier. This process runs within 24 hours and cannot be reversed. Before deleting a tier, verify whether affected members need to be migrated to a specific alternative tier first. ## Tier evaluation schedule Tier status updates run on a **daily automated schedule**. Changes to tier configuration — milestones, multipliers, or retention settings — take effect on the next scheduled evaluation run. For most programs, this means up to a 24-hour delay between a configuration change and visible member tier changes. If immediate tier assignment is required (for example, when a campaign involves instant tier upgrades), use the Tier API to set tier status programmatically. ## Troubleshooting **A member who crossed the Gold milestone is still showing as Silver.** * Tier evaluation runs daily. If the qualifying transaction was recent, wait until the next evaluation cycle. * Check whether the member's qualifying metric (points or attribute) actually meets the threshold after any reversals are subtracted. **A tier benefit was not credited when a member upgraded.** * Confirm the benefit was configured before the member crossed the threshold. * Benefits defined after a member has already achieved a tier are not backdated. **Members are not being downgraded when they drop below a threshold.** * Check whether the Tier Retention Period is enabled — a grace period may be preventing the downgrade. * If retention is enabled, confirm how many days remain in the member's retention window. # Tiers overview Source: https://help-loyalife.xoxoday.com/user-guides/tiers/overview See how Loyalife's tier system rewards engagement with milestone-based levels, multipliers, retention periods, and automated evaluation. Tiers let you reward your most engaged members with progressively richer benefits. Members at higher tiers earn more points, get better multipliers, or unlock exclusive rewards — creating a powerful incentive to stay active and increase spending. Loyalife automates tier evaluation and assignment, so members move up (or down) without manual intervention. ## How tiers work A tier is a status level defined by a **milestone** — a threshold of points, spend, or custom metrics that a member must reach to qualify. Once a member crosses a tier's milestone, they are upgraded and begin enjoying that tier's benefits and earning multipliers for all subsequent transactions. Tier evaluation runs on a daily automated schedule. Members are promoted or demoted based on their current qualifying activity against configured thresholds. ## Why tiers work Tiers create a loyalty loop. Members who are close to the next tier threshold increase their spending to qualify — a behaviour sometimes called "tier chasing." Once at a higher tier, members are motivated to stay there. This increases both transaction frequency and average spend. ## Tier structure A typical Loyalife program has a base tier (the entry level every member starts in) plus two to four levels above it: | Tier | Milestone (lifetime points) | Multiplier | Upgrade benefit | | ------------- | --------------------------- | ---------- | ------------------------------------ | | Silver (base) | 0 | 1.0× | — | | Gold | 5,000 | 1.5× | 200 bonus points | | Platinum | 15,000 | 2.0× | 500 bonus points + exclusive voucher | | Diamond | 50,000 | 3.0× | Premium concierge benefit | ## Qualification methods Loyalife supports multiple approaches to determining tier eligibility: | Method | How it works | | ------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------- | | **Points (Lifetime)** | Counts all points earned since enrollment — members never lose qualification once reached | | **Points (Rolling period)** | Counts points earned within a recent window (e.g., past 12 months) — members must maintain activity to keep their tier | | **Aggregated attributes** | Qualifies members based on custom metrics configured in the Rule Engine — for example, total spend, account balance, or number of transactions | | **Both points and attributes** | Members must satisfy both points and attribute thresholds simultaneously | ## Tier retention period The **Tier Retention Period** defines how long a member stays in a tier after they qualify. This is separate from the qualification method and lets you offer grace periods before downgrading members who dip below a threshold. | Setting | Behavior | | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------- | | Retention disabled | Members are evaluated against the threshold continuously — downgrade happens as soon as qualifying activity drops below the threshold | | Retention enabled | Members who drop below the threshold keep their tier status for the configured number of days before being downgraded | **Example:** A 365-day retention period means a member who qualified for Gold last year retains Gold status for the rest of the year even if they don't transact again. All changes to the Tier Retention Period — both toggling the setting on/off and changing the number of days — are captured in the **Audit Trail** with a timestamp, actor, and the before/after value. ## Tier benefits Benefits are awarded when a member **first achieves** a tier's milestone. They are not awarded to members already in the tier when you configure or edit the benefit. | Benefit type | Description | | ---------------- | ------------------------------------------------------------------------------------------------------------- | | Bonus points | A fixed number of points credited on tier achievement | | Point multiplier | A percentage increase applied to all future point earnings (e.g., 1.5× means 50% more points per transaction) | | Custom benefits | Vouchers, service upgrades, or exclusive access configured outside the points system | ## Manual vs automated assessment | Mode | When to use | | ------------------------ | ----------------------------------------------------------------------------------------------------------------- | | **Automated** | Loyalife evaluates and updates tiers daily based on configured criteria — suitable for most programs | | **Manual (Tier API)** | Your external system calls the Tier API to set a member's tier — suitable when tier logic lives in your platform | | **Manual (Rule Engine)** | Campaign-driven tier changes based on custom Rule Engine flows — for programs with complex conditional tier logic | ## Real-world tier examples Qualification: number of nights stayed in a rolling 12 months. Retention: 2-month grace period before downgrade. Benefits: priority check-in, room upgrades, lounge access at higher tiers. Qualification: combined average daily balance over a rolling 3-month window (aggregated attribute). Rolling evaluation with a 3-month grace period. Benefits: fee waivers, higher cashback rates, dedicated relationship manager. Qualification: lifetime points accumulated. No rolling window — once Gold, always Gold (lifetime basis). Benefits: early sale access, free shipping, birthday bonuses. ## Next steps * [Configure tiers](/user-guides/tiers/configure-tiers) — enable tiers and set up your qualification method and base tier * [Manage tiers](/user-guides/tiers/manage-tiers) — add, edit, and delete tier levels