LOYALTY RELEASE 26.6.0

 

Activity Processing: First Punch and First Award Tracking for Punch Cards

Available to all CLIENTS

Background

Punch Cards are a proven way to drive repeat behavior, but previously Loyalty did not explicitly distinguish a Member’s first punch or first award from subsequent activity. By not distinguishing these behaviors, the platform limited visibility into key early moments in the Punch Card journey, moments that often matter most for engagement measurement and downstream activation.

Solution

Enterprise teams need a reliable way to identify when a Member truly starts progressing toward a reward and when they receive their first award, without relying on inference or custom logic. Loyalty now tracks first punch and first award events as distinct Punch Card Activities. These dedicated events clearly indicate when a Member records their initial punch and when they earn their first award, while preserving existing Punch Card behavior and integrations.

Key Capabilities:

• Clear visibility into early engagement: Identify when Members first engage with a Punch Card and when they earn their first reward.

• More reliable analytics and downstream activation: Use first punch and first award events as precise signals for reporting and journeys.

• Clear, one‑time milestone signals: First punch and first award events are recorded explicitly, providing a reliable marker for early Punch Card engagement.

What it looks like in Loyalty

Loyalty now publishes dedicated Activity events for a Member’s first punch and first award on a Punch Card, alongside existing Punch Card Activity types. These events occur once per Punch Card lifecycle and provide a clear marker for the start of progression and initial reward fulfillment.

This enhancement helps Loyalty teams better understand Member momentum, and measure program effectiveness, without adding operational complexity.

For more information on Punch Cards, see Getting Started with Punch Cards.

 

Imports: Order Imports Now Support Separate Header and Line Item Files

Available to all CLIENTS

Background

The basic Order Import Definition expects a single file containing all Order data, including Order header-level and item-level Attributes. However, some Point of Sale systems extract the Order header and item data into separate files.

Solution

Loyalty now supports importing Orders when header and line-item data are delivered in separate files. With the new Order (Header + Item) Import Definition, teams can configure, pair, and merge header‑level and item‑level data directly within Loyalty, without pre‑processing or custom ETL work.

Header and item files can be paired using one of the following three methods:

• Index-based pairing to match files by sorted order

• Pattern-based pairing to match shared filename segments

• Shared date pairing to match files by an extracted date in the filename

Record Keys define how header and item records relate to one another. These keys ensure item‑level records attach to the correct Order header across both files. Header and item fields can be mapped and transformed together in a single import configuration. Teams can apply standard transformations, lookups, or advanced Groovy logic to normalize data as needed. Import jobs display paired header and item files together in Job History, making it easier to monitor status and troubleshoot when needed.

Why It Matters

• Reduces integration effort: Teams no longer need to merge files upstream or build custom tooling to meet import requirements.

• Supports real world POS data models: Loyalty now aligns more naturally with POS systems that separate transactional data by design.

• Preserves downstream consistency: Orders continue to flow through Loyalty as a single, complete record, ensuring reporting, activities, and loyalty logic remain intact.

• Accelerates Time to Value: Clients can move faster during onboarding, expansion, or peak sales periods, even with limited technical resources.

What it looks like in Loyalty

A new Order (Header + Item) Import Definition allows for separate configuration of Order header files and Order item files, then merges them into a single, complete Order dataset. This enhancement removes a common integration barrier for Point of Sale systems that naturally separate Order data, while preserving the integrity of downstream Order and Activity processing.

For more information, see Configure an Order (Header + Item) Import Definition.

 

Imports: Offer Selection Clarity in Import Definitions

Available to all CLIENTS

Background

Enterprise programs often manage large volumes of similarly named Offers. When importing Offer-related data in the Advanced Import feature, the Offer selection drop-down menu displayed only the Offer names, and not the Offer IDs.

Solution

We’ve improved the Advanced Import user interface by adding the Offer ID alongside the Offer Name in the Offer selection drop-down menu, and by defining a consistent sort order for Offers within this drop-down menu. This update applies to Offer Response, Offer Response with Certificate Assignment, and Offer Certificate Advanced Imports.

Including the Offer ID removes guesswork and reduces selection errors during import configuration. A predictable sort order improves operational consistency and usability, and ensures alignment across QA, staging, and production environments, helping teams move confidently between them.

Note: This is a user interface-only enhancement; Offer import behavior and processing remain unchanged.

What it looks like in Loyalty

When configuring an Offer-related Advanced Import, the Offer selection drop-down menu now displays Offer ID + Offer Name together (for example, "ID-100 Offer_28801 2206"), giving teams clear, unambiguous visibility when choosing Offers. The drop-down menu also follows a defined sort order, ensuring Offers appear consistently across environments.

Clear identification and stable ordering within the Offer select menu streamlines setup and review, saving time without changing downstream outcomes.

 

Platform: Legacy Common Event Program Settings Retired for Consistent Processing

Available to all CLIENTS

Background

Loyalty has retired legacy Program Settings previously used to control common event submission behavior. These settings are no longer visible or configurable in the Program Settings screen, and the underlying functionality they governed is now enabled by default across the platform.

Solution

This update removes unnecessary configuration choices while ensuring consistent, reliable common event processing for every program. By standardizing this behavior:

• Teams gain confidence in outcomes: Event handling follows a consistent, always‑on approach without requiring manual setup.

• Operational complexity is reduced: Fewer settings mean fewer decisions, less maintenance, and less room for misconfiguration.

• Programs scale more reliably: Standardized processing supports predictable behavior across environments and use cases.

What it looks like in Loyalty

Program Settings related to Submit Event to Common Event Stream and Common Event Objects configuration have been removed from the Program Settings screen. These behaviors now run automatically and consistently across all programs. Deprecated configuration options are no longer exposed to clients.

This change reflects our continued focus on simplifying program management while strengthening the consistency and reliability enterprise Loyalty teams depend on.

For more information, see Getting Started with Program Settings.

 

Updated Phone Validation Support

Available to all CLIENTS

Background

We’ve updated the phone validation module in this release to align with recent changes in acceptable international phone formats with the intent to deliver more accurate and comprehensive global phone validation behavior.

 

Resolved Issues

Bug Fixes

• Resolved an issue where Profile Stream tier fields could fall out of sync and trigger duplicate profile updates, keeping tier data accurate and reducing downstream noise.

• Resolved an issue where pending purchase activity metrics could display as zero when Last Activity Expiration and a minimum Metric threshold were enabled.

• Resolved an issue where Member Activities remained visible after deletion, ensuring removed Activities no longer appear in the platform interface.

• Resolved an issue where Activity reprocessing applied updated Earn Rules, ensuring historical Activities retain their original Metric calculations.

• Resolved an issue where export jobs sent notification emails even when notifications were turned off, restoring expected control over email delivery.

• Reviewed report configuration to reduce the amount of data needed to complete it.

• Resolved an issue in householding accounts where parent tiers reset incorrectly after expiration, ensuring tier status is reassessed based on earned Metrics as expected.

See Loyalty Upcoming Releases for the platform release schedule.

See System Maintenance for details on the next system maintenance window, per region.

The status page provides you with regular updates regarding the status of the Loyaltyplatform in the event of a major system incident in your region. In this article we’ll explain the information you will see and how to subscribe to the Loyalty notification system to receive regular updates on the platform status, which we highly recommend to all users.

See Platform Status for more details.