Loyalty tier upgrade not triggering after points redemption event

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

Our loyalty program has a tier structure where members should automatically upgrade when they reach certain point thresholds. However, we’re seeing that tier upgrades are not triggering after points redemption events, even though the net points balance meets the upgrade criteria.

For example, a member redeems 500 points (bringing balance from 2000 to 1500), then earns 1000 points (balance now 2500). The tier upgrade rule is set to trigger at 2500 points for Gold tier, but the member remains in Silver tier. The tier evaluation logic seems to only run on point accrual, not after redemption events that might affect eligibility.

We’ve configured the custom rule in Program Rules to evaluate tier on both accrual and redemption events, but it’s not working as expected. The points redemption event itself processes correctly and updates the balance, but doesn’t trigger the tier evaluation workflow. This results in incorrect member status and affects their benefits eligibility.

system 2

The root cause of your tier upgrade issue involves three interconnected configuration problems that need to be addressed systematically:

1. Custom Rule Configuration - Event Triggers

Navigate to Loyalty Programs → Program Rules → Tier Evaluation Rules. Your current rule likely only has ‘Points Accrual’ as a trigger event. You need to configure it to trigger on multiple events:

  • Add ‘Points Redemption’ as a trigger event
  • Add ‘Points Adjustment’ as a trigger event
  • Enable ‘Member Points Balance Changed’ umbrella event
  • Set evaluation timing to ‘Immediate’ rather than ‘Batch’

The critical setting is ensuring the rule subscribes to the ‘Member Points Balance Changed’ event, which encompasses all point transaction types including redemptions.

2. Tier Evaluation Logic - Transaction Sequencing

The tier evaluation logic in OCX 23C has a transaction sequencing issue. The evaluation runs within the same database transaction as the points redemption, but reads the member balance before the transaction commits. To fix this:

  • Edit your tier evaluation rule
  • Change execution mode from ‘Synchronous’ to ‘Asynchronous with 30-second delay’
  • This ensures the points balance is fully committed before tier evaluation reads it
  • Alternatively, enable ‘Post-Transaction Evaluation’ flag in advanced rule settings

The 30-second delay gives the redemption transaction time to commit and the member record to reflect the updated balance.

3. Points Redemption Event Configuration

Verify that your points redemption event is properly configured to trigger downstream processes:

  • Go to Program Configuration → Event Management
  • Locate ‘Points Redemption Completed’ event
  • Ensure it publishes ‘Member Balance Updated’ notification
  • Check that tier evaluation rule is subscribed to this notification
  • Verify event priority is set lower than balance update (so balance updates first)

Complete Solution Steps:

  1. Update tier evaluation rule to include all point transaction event types
  2. Change rule execution to asynchronous with delay
  3. Enable post-transaction evaluation in rule configuration
  4. Verify event subscription chain: Redemption → Balance Update → Tier Evaluation
  5. Test with a member who is close to tier threshold
  6. Monitor the event log to confirm evaluation triggers after redemption

Testing Protocol:

Create a test scenario:

  • Member with 2400 points (100 points below Gold tier threshold of 2500)
  • Redeem 100 points (balance drops to 2300)
  • Accrue 300 points (balance rises to 2600)
  • Verify tier upgrades to Gold immediately after accrual

This tests both the redemption event handling and the subsequent tier evaluation on the next qualifying transaction.

Additional Considerations:

If you have multiple tier thresholds, ensure each tier rule has the same event trigger configuration. A common mistake is configuring events only on the initial tier rule but not on subsequent tier upgrade rules. Each tier transition rule needs its own complete event subscription configuration.

For high-volume programs with frequent transactions, consider implementing a hybrid approach: immediate evaluation for tier upgrades (members like seeing instant gratification) but batch evaluation for tier downgrades (less time-sensitive and reduces system load).

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

Check if your tier evaluation rule is configured to trigger on the correct event types. In the Program Rules configuration, you need to explicitly add ‘Points Redemption’ as a trigger event, not just ‘Points Accrual’. The default configuration often only includes accrual events.

4

I’ve seen this in OCX 23C. The tier evaluation logic has a timing issue with redemption events. The rule engine evaluates tier eligibility BEFORE the points balance is updated in the member record, so it sees the old balance. You need to add a scheduled process that runs tier evaluation as a separate step after redemption transactions are committed. Set it to run every 15 minutes or use a trigger-based approach with a slight delay.

6

Your custom rule configuration might be missing the tier recalculation flag. In Program Rules, there’s a checkbox for ‘Recalculate Tier After Transaction’ that needs to be enabled for both accrual and redemption event types. Also verify that your tier threshold rules are using ‘Current Balance’ rather than ‘Lifetime Points’ as the evaluation metric.

7

Double-check the event subscription configuration in your loyalty program setup. Points redemption might not be publishing the correct event type that your tier evaluation rule is listening for. Navigate to Program Configuration → Event Subscriptions and ensure ‘Member Points Changed’ event includes redemption transactions, not just accruals.

8

There’s a known issue in OCX 23C where tier evaluation on redemption events doesn’t work properly if you have multiple concurrent transactions for the same member. The evaluation logic can read stale balance data. We implemented a workaround using a custom scheduled process that identifies members whose balance changed in the last hour and forces a tier re-evaluation. Not elegant, but it solved the immediate problem while waiting for Oracle to patch it.

9

Check if your tier upgrade rule has the correct evaluation frequency setting. In some configurations, tier evaluation is set to run only daily or weekly rather than real-time. For immediate tier upgrades after redemptions, you need real-time evaluation enabled, which requires additional configuration in the Program Rules engine settings.