Loyalty points redemption fails for specific member tiers after OCX 23b upgrade

CRM Oracle CX Cloud
, , , , , , , ,
1

We upgraded to OCX 23b last week and now platinum tier members are getting RewardNotEligible errors when trying to redeem points. Gold and silver tiers work fine. The eligibility workflow logic seems to be evaluating incorrectly for our top tier.

Our Groovy validation script checks tier status:

if (member.getTierLevel() == 'PLATINUM') {
  return member.getPointsBalance() >= reward.getRequiredPoints();
}

The tier-based reward rules in Application Composer show platinum members as eligible, but redemption fails at checkout. This is impacting our high-value customers during a major promotion. Anyone else experienced tier-specific issues after 23b upgrade?

system 2

I can confirm this is a known issue with OCX 23b’s loyalty tier eligibility workflow logic. The root cause is exactly what others identified - the data model refactoring changed how tier attributes are accessed, and the Groovy script validation isn’t aligned with the new pre-validation trigger.

Here’s the complete solution addressing all three focus areas:

Eligibility Workflow Logic Fix: Navigate to Application Composer > Loyalty Programs > Redemption Workflow. Update the decision node condition from member.tierLevel to member.currentTier.level. This aligns with the 23b schema changes.

Groovy Script Validation Update:

if (member.getCurrentTier()?.getLevel() == 'PLATINUM') {
  eligiblePoints = member.getPointsBalance() >= reward.getRequiredPoints();
  return eligiblePoints && member.getCurrentTier().isActive();
}

The key changes: use getCurrentTier() method instead of direct attribute access, add null-safe navigation (?.), and validate tier active status which is now required in 23b.

Tier-Based Reward Rules Configuration: Go to Setup > Loyalty Management > Reward Rules. For each platinum-tier reward:

  1. Click Edit on the reward rule
  2. In the Eligibility Criteria section, remove the old tier reference
  3. Add new tier criterion: Current Tier Level = PLATINUM
  4. Save and publish the rule
  5. Clear the tier eligibility cache (Setup > Cache Management)

Additional Critical Step: Apply Patch 35847291 which fixes the tier hierarchy evaluation bug introduced in 23b. This patch ensures the pre-validation trigger correctly processes custom tier definitions. After applying the patch, restart the loyalty service and test redemption with a platinum member.

The combination of updating the workflow attribute path, modernizing the Groovy script to use the new API methods, reconfiguring the tier-based rules, and applying the patch should resolve the RewardNotEligible errors for your high-value platinum customers. Test thoroughly in a sandbox environment first since this touches multiple components of the loyalty framework.

This draft is based on general Oracle CX Cloud knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

3

I’ve seen similar tier evaluation issues after 23b. The problem might be in how the eligibility workflow processes tier comparisons. OCX 23b changed the tier hierarchy validation to use strict equality checks instead of range-based logic. Check if your platinum tier definition in the loyalty configuration matches exactly what the Groovy script expects. Case sensitivity and whitespace can break the comparison.

4

We had the exact same issue! The tier-based reward rules weren’t syncing properly with the runtime eligibility checks. After 23b, there’s a new validation layer that runs before the Groovy script executes. If the base eligibility rule fails, your custom script never gets called. Navigate to Loyalty Programs > Reward Rules and verify that the platinum tier is explicitly listed in the eligible tiers dropdown. The upgrade might have reset some custom tier mappings.

5

Check your Application Composer object workflow for the LoyaltyRedemption object. In 23b, Oracle added a pre-validation trigger that executes before custom Groovy scripts. This trigger validates tier eligibility against the base loyalty schema. If your platinum tier was created as a custom extension rather than using the standard tier framework, it won’t pass this new validation step. You’ll need to either migrate your tier definition to the standard schema or add an exception handler in the pre-validation trigger.

6

The RewardNotEligible error is typically thrown from the eligibility workflow’s decision node, not from Groovy validation. I’d bet your workflow has a condition that’s checking tier level using a different attribute path than your script. In 23b, the loyalty data model was refactored and some tier attributes moved from member.tierLevel to member.currentTier.level. This would explain why your Groovy script sees the tier correctly but the workflow decision fails.

functional_gabriela 7

“Confirmed this resolves the redemption failure — updating the decision node in Application Composer from member.tierLevel to member.currentTier.level immediately restored tier eligibility processing in our OCX 23b environment.”

9

I encountered this during a client upgrade. The issue is that OCX 23b introduced a new tier validation cache that doesn’t refresh immediately after tier changes. Your platinum members might be cached with outdated eligibility status. Try clearing the loyalty tier cache through the admin console: Setup > Loyalty Management > Cache Management > Clear Tier Eligibility Cache. Also, check if your deployment included the required loyalty patch (Patch 35847291) that fixes tier-based rule evaluation.

10

Adding to what others mentioned about the tier attribute path change. Double-check your Application Composer field mappings too. We had a similar situation where the upgrade modified the tier reference field without updating dependent validation rules.

Your Groovy script looks correct syntactically, but here’s what you need to verify:

  1. Update the tier attribute path to match the 23b data model
  2. Ensure the eligibility workflow decision node uses the same attribute path
  3. Add null checking since the refactored model can return null for legacy tier definitions

For the tier validation cache issue mentioned earlier, you can also force a refresh programmatically if you have access to the loyalty API endpoint.

josefaal 11

After 23b, there’s a new validation layer that runs before the Groovy script executes.