Usability improvement

• The Customers page and the Customer overview page under the Customer insight menu now loads significantly faster due to a series of targeted performance optimizations.

Compatibility improvement

• The compatibility of the Multi-accounts module has been extended to the Online treasure hunt module.
  The ‘Account’ field is now available on the configuration pages of online treasure hunts. The events related to treasure hunt participation (Treasure found) will be registered under the associated account in the customers' event histories.

Entities API enhancements

• The Entities API responses now include detailed information regarding multi-accounts, making the account settings accessible via the GET endpoint.
  With this enhancement, now the API provides specific details like account ID and name, offering a clearer understanding of how entities are associated with different accounts.

  Account information provided by the Entities API:

  "account": {
                  "id": "{account_id}",
                  "name": "{account_name}"
              }

• Antavo has enhanced error responses for attempts to retrieve non-API-friendly entities through the Entities API. A more precise error code (300706) has been introduced, and the error message has been refined to ‘Entity is not available as an API response’.

  Error response provided by the Entities API:

  {
      "error": {
          "type": "BadRequestException",
          "code": 300706,
          "message": "Entity is not available as an API response"
      }
  }

  Antavo has also introduced additional error codes for consistency. The list of error codes will be extended with the new codes shortly.

Usability improvements

• When importing coupon codes through the Import module, it was necessary to include the coupon pool ID in the coupon import file and also to select the corresponding target coupon pool under the Module options section of the import configuration interface.
  Starting from this release, adding the coupon pool ID to coupon import files is not mandatory if the coupon pool has been selected. However, by selecting the Based on the chosen file option, it is still possible to include the coupon pool ID.
  This development simplifies the import setup by dissolving the redundancy when uploading new codes to a coupon pool.

• The Transactions page under Customer Insights now features a Points burned column. This addition allows customers to view the number of points used in each transaction, enhancing the ability to track redeemed points.

• The Changes tab under the Settings menu is now available to track any configuration changes made in the Backoffice by authorized users.
  This new section facilitates the monitoring of modification, unveiling usage trends, and identifying potential unexpected changes.

Feature enhancements

• An async web request (JSON payload) processing mechanism has been introduced for Shopify webhook requests sent to the customer/create endpoint, which ensures smooth processing of loyalty program member registrations from Shopify.

• In the Wallet module, changes have been made to the pass template editor of Google Pay passes:

  • Both the Content and Template pages now contain the Messages, Text module and Links configuration section. This adjustment ensures that updates are delivered in the proper contexts:

    • Content settings - updates are delivered to a specific customer’s pass if there’s a change in customer data field values

    • Template settings - updates are delivered to all customers' passes if changes are made in the configuration of the pass template

  • The Tier Label, Tier settings were moved from the Content to the Template page of the membership pass template editor to make sure the updates are delivered to all customers' passes as a general template update.

• When using Entities API to create a new reward, the availability of the reward can now be restricted to specific segments without the need for Backoffice configuration. The restriction setting can be applied to the reward by submitting the ID of segment(s) in the multi-select segment parameter.

  Entities API endpoint to send the PUT request to: entities/rewards/reward

{
  "name": "10% coupon",
  "description": "Enjoy 10% off your next order.",
  "price": 100,
  "type": "coupon"
  "segment": ["{segment_id}"]
}

• A new setting has been added to the Webhook message workflow node to set up the timeout value of the webhook messages.

  This sets the interval while Antavo waits for a response before it registers the webhook message as a failed attempt. Setting a timeout value offers multiple advantages, serving as a mechanism for efficient error handling, while also preventing issues such as infinite processing and delays in response delivery.

Klippa integration

• As part of this release, Antavo is introducing its integration with Klippa. Klippa is an automated document processing tool that transforms customer-scanned purchase receipts into digital transaction data.
  The integration converts transaction data into Checkout events. These events are then recorded in customers' event histories in the database, allowing them to be rewarded with loyalty points.
  A detailed integration guide is available under the Antavo Documentation here.

Usability improvement

• The Preview section of the Incentivized purchase module can simulate point calculation if points are to be earned based on the transaction total.

Feature enhancement

• Explicit null attribute values sent to the /events, /events/bulk, and /entities API endpoints are now processed and registered with the respective event or entity attribute.
  This implies that any previously stored value for the attribute is cleared out and replaced with a null value.

• The responses provided by the /activities and /activities/contests Display API endpoints now include not only active but scheduled contests as well. This feature allows the display of contests on the membership site that are set to launch in the future.

• When the ‘Keep the highest tier level’ tier expiration methodology is used in the Tiers module, the following implications of manual tier-up and tier-down events have been introduced:

  • If a customer has been manually upgraded to a higher tier in the Backoffice, they cannot be downgraded until they either exceed the manually set tier or their tier expires.

  • Customers cannot be manually downgraded to a tier lower than the one they qualify for based on the number of tier points they've collected.

Compatibility improvements

• The compatibility of the Multi-accounts module has been extended to the Social follow and Gamified reviews modules.
  The ‘Account’ field is now available on the configuration pages of the Gamified reviews and Social follow modules. The events related to activities rewarded by these modules (review writing, Facebook account connection, and Twitter account follow) will be registered under the associated account in the customers' event histories.

Bulk reward claim solution

• The first iteration of Antavo’s bulk reward claim solution has been released, with the aim of handling use cases where rewards should be assigned to large segments of customers or the entire customer base simultaneously.

  Bulk reward claim is introduced as an API-only feature, it’s not possible to mass-claim rewards for customers in the Backoffice.

  Detailed instructions on the use of the newly introduced reward claim endpoints are to be published by 10th November under the Developer Documentation.

Platform usability improvements

New validators have been implemented on 2 configuration pages of the Backoffice:

• Coupon pattern uniqueness validation in the Coupons module
  The validator ensures that coupon pools don’t use the same pattern to generate coupon codes. This prevents the same coupon codes from being generated in multiple coupon pools.

• Time input validator for scheduled imports
  The validator checks if the hour and minute values have been configured in a valid format. This prevents the import from not being triggered due to an invalid date format.

Upgrade to v2 Twitter API

• To secure the smooth running of functionalities related to customers' activities on Twitter (Social share and Social follow), Antavo’s Twitter integration has been updated to use the endpoints of the v2 Twitter API.

Pass template switch

The template switch functionality of the Wallet module is now available which introduces the option to swap the template of a customer’s pass.
The Workflows module has been employed to implement the functionality through the use of two newly added workflow nodes:

• Pass Lookup node to search for the customer pass that should be updated

• Swith Pass Template node to switch the template of the pass that has been found by the Pass Lookup node

As the template of a pass may change through the template switch mechanism, the pass download URL that is returned by the Display API endpoint now includes the pass ID instead of the pass template ID in order to allow direct references to individual passes.

• Google: /v2/customers/{{customer_id}}/wallet/google/{{pass_id}}/download

• Apple: /v2/customers/{{customer_id}}/wallet/apple/{{pass_id}}/download

The previously generated download URLs are still operational, but new responses will only provide the download endpoints with the pass ID included.

Deprecated functionality

• The Beacons module has been deprecated, which means that support for the module is discontinued and it will be removed soon.

Transactional earn and burn feature enhancements

• The Incentivized purchase module is used to reward customers' purchases with points, by defining the calculation method of the number of points to earn on the level of individual items within the transaction. With this release, we’re introducing the possibility to attribute points not just on the item base but also on the total checkout value.
  This solution provides an easy-to-follow ‘you get points for what you pay’ rewarding mechanism for customers and it is also useful if discounts are not administered on the item level, but applied on the cart level before the transaction is registered.

The default setting is the item-level scenario, therefore the modification of the current configuration is only necessary if the new option is to be used.
Please contact the Antavo Service Desk if you want to switch to the new transaction level calculation.

• When a checkout event is registered in Antavo, points can be assigned immediately or after a pending period. The auto-accept and reject functionality of the Checkout accept module is available to configure the time period while the purchase is in pending status before it is rejected or accepted automatically.
  Now it is possible to overwrite the automatically calculated acceptance or rejection date of specific transactions via API, by sending the date value in the auto-accept attribute of the Checkout and/or Checkout accept events.

  Events API endpoint to send the POST request to: /events

Checkout event example:

{
	"action": "checkout",
	"customer": "demo_customer",
	"account": "account_1",
	"data": {
		"auto_accept": "2023-12-31",
		"transaction_id": "trx_id",
		"total": "150",
		"items": [
			{
				...
			},
			...
		]
	}
}

Checkout update event example:

{
	"action": "checkout_update",
	"customer": "demo_customer",
	"account": "account_1",
	"data": {
		"auto_accept": "2023-12-31",
		"transaction_id": "trx_id",
		"total": "150"
		"items": [
			{
				...
			},
			...
		]
	}
}

• The ‘Currency change’ button has been removed from the customer profile page under the Customer Insights menu. With the introduction of advanced currency-specific earn and burn rules, the checkout currency is handled seamlessly on the checkout level, making the change of customer currency redundant.

Contest lite module developments

• In the previous release, the count property was introduced to include multiple contest entries within one request.
  The process has been further optimized by the introduction of the weighted contest entry event. This means that even if the count value in the contest entry request is greater than 1, only one single Promotion enter event is registered on the customer’s event history with multiple entries included. By reducing the number of events being registered, customer’s event histories are more transparent and the event registration process is faster.

With the optimization of contest entry event handling, the 20-entry limit has been removed in the Participate in contest workflow action node. The number of entries to assign to the customer within one workflow is now unlimited.

Platform usability improvement

• The start and end date of campaigns has to be set based on the UTC timezone. To help the understanding of campaign workflow schedules compared to the local timezone, the time is converted to the brand timezone and displayed under the start and end date configuration fields.
  The help text also highlights if the time falls on the next or previous day in the brand timezone.

Tier expiration mechanism enhancements

Two new tier expiration settings have been introduced for tier structures configured in the Tiers module.

• Cross tier membership refund handling (available calendar expiration logic)
  If the checkbox is enabled and the checkout was made before the last calendar expiration date, tier points are not deducted and downgrading does not occur upon refund.

This way the refund of transactions made in previous periods will not affect the customer’s current tier status and progress in the tier structure.

Reset tier points on the expiration while keeping the highest tier in the next period (available for calendar and anniversary expiration logics)
The new Destination tier setting prevents customers from being downgraded from the highest tier they have reached in the previous expiration period based on the number of tier points collected. However, the tier points are reset to 0 on the expiration day, which means that customers have to earn their way from the bottom to achieve an even higher tier than what they reached in the previous period.
The new option does not allow setting grace periods:
❌ No Tier grace period, as the highest tier that customers achieved in the previous period is always kept until the next expiration date.
❌ No Tier points grace period, as tier points are reset on the expiration date regardless of when they were earned.

Using this logic, the frustration that expiration causes for customers can be reduced by giving them enough time to enjoy benefits, while still keeping them mindful of expiration dates.

Compatibility improvement

• The compatibility of the Multi-accounts module has been extended to the Offline treasure hunt module.
  The ‘Account’ field is now available on the configuration pages of offline treasure hunts. The events related to treasure hunt participation (Offline treasure found, Offline treasure code found) will be registered under the associated account in the customers' event histories.

Coupon-related feature enhancements

• A coupon’s claimed status indicates that the coupon has been assigned to a loyalty member. However, the member might lose the eligibility to use the coupon (eg. due to segment restrictions or fraudulent behavior)) and it is necessary to withdraw the coupon from its assignee.
  Previously, the only way to unassign the coupon (removing the tie between the coupon itself and the loyalty member) was to invalidate the coupon. With the introduction of the coupon_unassign event, it is now possible to unassign the coupon without invalidating it. This event changes the status of the coupon from claimed to unassigned which means that the coupon is available for future reassignment to another customer, therefore the system will not be loaded with invalid coupons.
  This event can be registered through the Events API or manually in the Backoffice.

The unassign_coupon event is compatible with the Pending events module which can provide a time window for a review before the coupon is disconnected from its assignee.

Events API endpoint to send the POST request to: /events
Payload to add:

{
  "customer": "{customer_id}",
  "action": "coupon_unassign",
  "data": {
    "code": "{coupon_code}"
  }
}

• The number of coupons issued to customers from bulk-generated coupon pools has been maximized to 1% of the unique combinations of the configured coupon pattern. This prevents the possibility that customers (who might be familiar with the pattern already) make lucky guesses on valid coupon codes.
  To ensure that 1% of the combinations is able to serve high demands, at least 4 variables have to be added to the coupon pattern.
  The dynamically calculated disclaimer inserted into the interface gives clarity on the limitations and restrictions.

When more than 5 million coupons are distributed, the number of coupons generated in one batch has been restricted to maximum of 5 million coupons, to ensure each batch is generated without delays.

Braze integration

Antavo is introducing its integration with Braze customer engagement platform. The integration provides the following benefits:

• Enables loyalty member data synchronization from Antavo to Braze.
  This allows businesses to have the loyalty data (eg. point balances and tier membership status) seamlessly transferred to Braze where it can be used for segmentation and personalization of communications.

• Antavo events can be synchronized to Braze with payload through the new Sync Braze events workflow action node in the Workflows module.
  This allows businesses to build communication journeys in Braze based on loyalty events triggered or processed in Antavo.

Platform usability improvements

• The currently used search filters on Backoffice interfaces are being replaced by single-line auto-fill filters that apply logical operators to find items more easily.
  With this release, the new filter will be introduced on the following pages:

  • Security log

  • Incoming webhooks log

  • Banned users

  • Transactions page

  • Maitre’D log

• The configuration interface of the Event trigger workflow node has been extended with the option to enter multiple events with the aim to save the time that users spend with configuration.
  The new multi-select field allows to have multiple events that may trigger the execution of a workflow, so there’s no need to configure a workflow for each triggering event.

The Event column has also been added to the log pages of workflows for traceability.

Changes in the status of modules

• Starting with this release, the Trusted sites and the Webhooks (beta) module will become the officially supported and recommended way to configure outbound communications from Antavo.
  With this change, the EARLY ACCESS tag will be removed from these modules in the Module list.
  The mentioned modules replace the previous Webhooks module which is now tagged with LEGACY status, suggesting that this module is still operational, but it is outdated.
  The new modules provide the interface to configure and manage multiple webhook authentication methods on one single page, there’s no need to configure the same endpoint every time it is used in a workflow.
  In case you use the old module, please contact the Antavo Service Desk to consult about switching to the supported modules.

Contest lite module improvements

The recent updates to the Contest Lite module's page aim to provide convenient access to key functionalities of the module. Here's what has changed:

• Each contest on the module's opening page now has a hamburger menu. Within this menu, the following options are available:

  • Edit – This button redirects the platform user to the editing page where contest details can be modified as needed.

  • Winner Selection – The action button for selecting winners of a contest after it has ended.

  • Copy ID – This new button copies the ID of the contest to the clipboard, which serves to conveniently paste the ID when configuring contest-related workflows in the Workflows module.

• Contest status – The status of each contest is now displayed below their name. This makes it easier to check if a contest is active, inactive, completed, or scheduled.

• It is now possible to archive inactive and completed contests in the system.

• Rewarding customers with multiple contest entries within one single promotion_enter event is configurable in the Workflow editor through the Participate in contest workflow node.
  With this release, the count property is also available to set the number of contest entries to assign when entering the customer through the Display API as well. This way there’s no need to send multiple requests to register each entry, which helps businesses to save network bandwidth and build campaigns including contest entries at scale.

  Display API endpoint to send the POST request to: /customers/{customer_id}/activities/contests/{contest_id}/enter
  Payload to add:

{
    "count": {number_of_entries}
}

• With our 2023-06-13 release, the contest_entry_revoke event was introduced to delete customers' entries to contests configures in the Contest lite module.
  After the current release, it is the newly introduced refund_contest_entry event that gives back the points to the customer point balance instead of the contest_entry_revoke event. The new event is automatically written down if the refund_points boolean attribute of the previously introduced contest_entry_revoke event is registered with true value.
  This change makes it possible to use the new refund_contest_entry event as an event trigger in workflows to set up automated mechanisms (eg. adding the customers to a list or notifying them about refunded points via email).

Multilanguage support

• So far, names of questions under the Gamified profiling module could be translated to languages added previously in the Multilanguage module.
  Now the ‘Translate’ button is available to translate the text values of the possible answers as well.

In case the Accept-Language header is added to the request sent to the Display API endpoint, the response will include the translated values. There’s no need to translate the texts in the website environment when displaying the answers, the values can be inserted from the response.

Display API endpoint to send the GET request to: /customers/{customer_id}/activities/{flow_id}/next
Header: Accept-Language={language_id}
Response provided:

{
  "data": {
      "type": "like",
      "title": "{translated_title}",
      "description": "{translated_description}",
      "multi-choice": false,
      "position": 2,
      "answers": [
        {
          "id": "649ae9ab5118f301d459bc65",
          "text": "{translated_answer}",
          "tags": [],
          "image": {
            "small": "{image_URL}",
            "medium": "{image_URL}",
            "large": "{image_URL}",
          }
        }
      ],
      "_actions": {
        "answer": {
          "method": "POST",
          "url": "{endpoint_URL)"
        }
      }
    }
  }

Contest lite module developments

• The opening page of the Contest lite module now presents a list of contests sorted primarily by start date. The next criterion is the end date; followed by an alphabetical listing by name. This sorting mechanism facilitates efficient navigation, and the chronological order allows users to conveniently track the progress of ongoing contests.

• Participants of segment-restricted contests can now be excluded from the winner selection process if they are not part of the segment by the time of winner selection.

Integration update

• The deferred web request (JSON payload) processing mechanism that was introduced with the previous release package, has been extended to Shopify webhook requests sent to the orders/fulfilled, orders/cancel, and orders/delete endpoints.

Feasibility updates

• When updating brand settings in the Backoffice, validation is performed on a per-setting basis: only the modified brand properties are updated and validated when a setting is saved, ensuring that the current updates can be successfully saved.

• To avoid misunderstandings and inconsistent usage of accounts, Backoffice users are prevented from setting the account name as 'Default' in the Multi-accounts module. Saving an account name as 'Default' will trigger an error message.

• Private image handling option has been added to the platform. If the accessibility of images is set to private, the Display API endpoints return pre-signed URLs of media items uploaded to the Backoffice.
  Please contact the Antavo Service Desk if you want to get started with private image handling.

Integration updates

• Asynchronous web request (JSON payload) processing mechanism has been introduced for Shopify webhook requests sent to the orders/create and orders/updated endpoints. This ensures that Antavo responds instantly, and all the incoming requests in the queue get processed properly.

• New properties have been added to checkout, checkout_update, checkout_accept events to improve Antavo's Shopify integration. They can also be used outside of the Shopify integration.

• A new ‘Deferred sync’ checkbox on the Bloomreach settings page offers the solution to send customer update calls asynchronously.

• Resend mechanism has been introduced in the Webhook (beta) module. If a message fails, it is lined up in the queue and can get resent a maximum of five times if necessary.
  From now on, we advise using the Webhooks (beta) module as the primary webhook service (instead of the one called Webhooks). With the inclusion of the resend mechanism, this feature has now all capabilities that the original module has had, in addition, it simplifies the process of using webhooks by allowing you to pre-configure trusted sites, making it easier to manage and authorize webhook notifications to specific endpoints.

  To learn more about the advantages of Trusted sites and the utilization of the new Webhook message (beta) workflow node, please refer to the linked user manual resources.

Guest checkout handling

• When a guest checkout is claimed by a newly registered loyalty member, the points are allocated based on the checkout status.
  If the checkout is in a pending status based on the settings configured under the Checkout accept module, the points are added as pending points to the customer’s account and will be confirmed when the checkout_accept event is registered. If the checkout has already been accepted, the points are added as spendable points right away.
  The expiration date of the points is calculated based on the date of the checkout_accept event.

Contest lite module developments

• The Entity lookup workflow node now has the option to look for a contest based on the ID of the contest.

• Contests are now available through the Entities API.

• The contest revoke functionality has been introduced. The new contest_entry_revoke event can be used to remove customers' entries from contests if they are not eligible to participate in the contest anymore (eg. due to segment restrictions or fraudulent behavior). There’s an option to trigger this event through the Revoke from contest action node, by sending a request to the Events API or to the /revoke Display API endpoint provided by the Contest lite module.
  It is the refund_points boolean attribute of the contest_entry_revoke event, that controls if the points that the customer may have spent to enter the contest should be refunded to the customer’s point balance or not.

Tier mechanism enhancements

• A grace period for tiers and tier points/spend amount can now be configured under Tier structure configuration within the Tiers module.

  • The tier grace period ensures that no tier expiration will occur if a customer has been upgraded to a higher tier within a predefined time period from the expiration date.

  • The grace period applied on the point/spend amount carries the amount over to the next cycle if it has been collected within a predefined time period from the expiration date.

• A new tier expiration method is available that downgrades the customer maximum 1 tier in the tier structure if the threshold of the current tier is not met.

• If the tier point value of a point-based tier is reduced on the customer’s account, the number of tier points will be cut down points to maximum 0, even if the point deduction event would take away more than the customer’s current tier points value.

• The points_after_expiration customer property has been introduced that stores the number of tier points customers would have after the next tier expiration date.

  This new property is applicable in workflows, exports, and all customer filter options across the Backoffice. It is also accessible through the Customer API.

• The Tier recalculation workflow node is no longer available.

Coupon pattern update

• Uppercase alphabetic and alphanumeric characters can now be added to coupon patterns under Coupon pool settings.

Compatibility improvements

• The compatibility of the Multi-accounts module has been extended to the Challenges and the Friend referral modules.
  The account attribute can now be selected as a criterion under the ‘Filters’ section of the challenge editor, therefore only events with the attribute value of the selected account are counted into the challenge completion progress.
  The ‘Account’ field on the Friend referral module configuration interface is available to select to which account the referral points should be allocated via the referral_points and referral_bonus events.

• Spend-based tiers can now be associated with accounts. Only the spend amount of the account that is selected under the ‘Account’ field affects the customer’s tier status.

• The parallel use of the Pending events and Checkout accept modules is syntonized. To prevent inconsistencies, checkout-related events are not available under the Pending events module if the Checkout accept module is turned on.

• The card settings under the Friend referral configuration interface have been extended with ‘Translate’ buttons, so that translations of the card title and description texts can be added to each of the applicable languages.

• The following events have been added to the list of events that can be handled as pending events through the Pending events module: partial_refund, reward_transfer, release_points, refund_item, refund, and referral.

Addition to the release

• The Checkout accept module offers the option to automatically recalculate the auto accept or reject date of transactions when the transaction is updated by a checkout_update event.
  In case the Points economy or the Multi-accounts module is enabled, this setting is available under the Pending points tab of the configuration interface of these modules.

Loyalty feature enhancements

• The Tiered Campaigns feature has been updated to support two trigger types: event-type and transaction-type. The new, transaction-based trigger handles all events that have a transaction ID, while any other events can be activated using the event-type trigger.

  • Some of the event trigger types have been removed, such as checkout and checkout_item.

• Pending points (coming from pending checkouts) are now registered for Tiered campaign participants. This update also ensures that checkout_update and checkout_reject events modify the pending points from the tiered campaign. Tiered campaign bonus points will remain pending until evaluation. These points will not be awarded to the customer, if the acceptance does not happen before the campaign period ends.

• Challenges can now be exported. This enhancement is convenient when migrating content between environments or creating a large number of challenges. Kindly note that exporting this data model is only possible in JSON format, and CSV is not available.

Enhancements to scheduling options

There have been multiple improvements that affect scheduling settings in the Backoffice.

• The node that triggers workflows based on a specific date, known as ‘On a date’ can now execute the flows annually, in addition to daily, weekly, and monthly triggers.

• When putting the letter 'L' in a service automation (cron) job setting’s ‘Day of month’ field, the last day of the month will be considered as the execution date.

  This scheduling option is also available when configuring imports, exports and ‘On a date’-triggered workflows.

• The configuration of imports, exports, and workflows (including both campaigns and ‘On a date’-triggered general workflows) now reflects the actual execution and is now based on the UTC timezone and displayed in the Backoffice accordingly.

  This is important to guarantee consistent timing of these processes, preventing discrepancies due to different timezones, international date line crossings, or differences for countries applying daylight saving time.

Earn rules

• Segment-specific earn rules can be configured in the Incentivized purchase module and the Earn rules tab Multi-accounts modules. Each of these special rules can be further specified with currency-based calculations.

• The calculator that appears on the interface of both modules has also been redesigned to provide a clear understanding of the calculation method that is applied based on the configured segment and currency-specific settings as well.

Interface enhancements

• New labels have been introduced on the Event history page of the customer profile that indicates the status of the points earned through registered events.

  • EXHAUSTED - points have been spent already

  • EXPIRED - points have expired

  • EXPIRING - points are about to expire the next time the scheduled expiration service runs

• The accessibility of certain modules is displayed on the Modules list with newly inserted tags.
  UNDER DEVELOPMENT EARLY ACCESS DEPRECATED LEGACY

Compatibility improvements

• The following events have been added to the list of events that can be handled as pending events through the Pending events module: checkout, checkout_item, checkout_claim, coupon, coupon_unredeem, coupon_redeem, coupon_transfer, coupon_invalidate, coupon_create, share, share_impression, and reward_revoke.

• The compatibility of the Multi-accounts module has been extended to the Instagram contests module. The ‘Account’ field is now available on the configuration pages of Instagram contests. The events related to contest participation (contest_enter, winner, non_winner) will be registered under the associated account.

Multi-accounts

• The compatibility of the Multi-accounts module has been further extended, the ‘Account’ field is now available on the Quizzes and Gamified profiling module configuration pages as well.
  The points that customers earn when completing quizzes and profiling question flows will be added to the selected account.
  The related events must have the same account property value as of the configured quiz or question flow.

• When configuring new entities, assigning an account is now a mandatory setting throughout the Backoffice editor interfaces. The default account is pre-selected in the ‘Account’ fields, you can use the dropdown list to assign another account.

• A warning message is displayed on the screen if there’s no default account selected in the Multi-accounts setting.
  To facilitate the configuration of the default account, the first account created in the Multi-account module is selected as the default account automatically upon activation.

Point handling

• A new type of point expiration logic has been introduced in the Expiring points module. Using the ‘Anniversary’ option, the point expiration date occurs annually, on the date stored in any (required) date or datetime type of customer attribute of each customer.

• Two options were added to the Expiring points module to control when points reassigned to the customer through refunds should expire. Points can either keep the original expiration date or have a new expiration date calculated based on the current expiration settings.

• The ‘Earn rules’ interface of the Multi-accounts and Incentivized purchase modules has been extended with the option to define multiple currency-based point calculations in addition to the default percentage value.

Tiers

• A new, optional field has been added to the Tiers module, which allows the definition of actions that decrease tier points and may trigger a tier_down event consequently.
  This field can be found in the Point-based tier’s structure editor, right below the field that defines actions for tiering up.

Jobs

• The Jobs tab has been introduced under the Settings menu where cron jobs can be created and managed. The Log subpage of each configured job shows the history of cron jobs processes. The access to actions and logs related to jobs can be restricted to specific user roles under the Roles tab.

Checkout accept

• The auto-accept date of transactions can now be updated through the checkout and checkout_update events. The auto-accept date value of these events is copied to the transaction that has the same ID as specified in the transaction ID field of the checkout or checkout_update event.

Webhooks

• The new Webhooks (beta) module now allows the handling of dynamic URLs. Among the settings of its workflow node, there is a new field where additional parameters can be added to the end of the given site’s URL.

• Also, the Webhooks (beta) module page has now a ‘Queue’ submenu where Backoffice users can monitor the status of the webhook requests in case of asynchronous processing.

Platform interface enhancements

• The user interface of the Backoffice is changed by adding a > icon at the end of each menu row so that the menu item can expand. This way, Backoffice users can see more clearly what are the main menus and submenus.

• The Security logs page now lists 'Onboarding' as a new event type. This addition distinguishes regular logins and those when a newly created Backoffice user logs in for the first time.

• On the customer Events history page, the Transaction ID value of the checkout and checkout_update events has been serving as a link to the Transaction details page. With the last release, hyperlinks were added to the refund, refund_item, partial_refund and point_unburn events as well.

• The configuration page of the Burn rules module is updated. The redesigned interface provides a clear understanding of the calculation method that is applied based on the configured settings.
  This update was added to the Burn rules tab integrated into the Multi-accounts module as well.

API enhancement

• Pagination has been added to the /customers endpoint. Long responses can be broken up into small components.

Loyalty feature enhancements

• Tier expiration setup options are now extended with a new checkbox called ‘Downgrade’.

  If a customer's events would lead to a tier downgrade, the loyalty administrator can either downgrade the customer or by leaving the box unchecked, protect the customer from being downgraded until the next tier expiration date, irrespective of the events or point balance changes.

• Generating bulk coupons is now available. By defining the desired number of coupons in the Backoffice -ranging from 1 and 100 million-, the coupon codes will be generated and exportable right away.

• Customer labels are now introduced. Labels are descriptive tags that can be attached to customers, representing various characteristics such as user preferences, or any assignment that was appended from integrated CDPs. They appear in the 'Labels' field under the customer's profile in the Backoffice; as well as being listed under a new menu item in the Customer Insights module.

• The execution of customer mapping rules has been optimized to make sure updates are properly handled. Customer updates trigger the rules to run for the affected customers, and configuration updates of mapping rules trigger the rule to run for the whole customer base.

Webhooks (beta)

• The new ‘Webhook message (Beta)’ workflow action node has now been enhanced to send async requests to a third-party website.

Multi-accounts

• The compatibility of the Multi-accounts module is being extended.
  A new ‘Account’ field has been added to the configuration interfaces of the Prize wheels and the Contest lite modules. The points that customers spend to enter prize wheel- and contest-type promotions will be deducted from the selected account.

• Release and checkout events must have the same account property value as of the preliminary reserve event.
  Campaign_bonus_revoke events must have the same account property value as of the preliminary campaign_bonus event.
  If the account value of mentioned events is different, the events will be rejected and if empty, the account property will be automatically populated with the account value of the preliminary event.

• A new configuration option has been added to the Multi-accounts module that forces the incoming API request related to a point-burning entity - reward, prize wheel, contest - to have the same account value as the configured 'Account' field value of the entity.
  If an entity is added in the new multi-select force match field and the account value of a related request is different, the events will be rejected and if empty, the account property will be automatically populated with the account value of the configured entity.

Refund transactions

• The refund_amount action is now deprecated.

• The refund_item event now restores any associated points burned in the transaction relating to the refunded item.

Campaigns, workflows

• The Tiered campaigns editor is now available in the Backoffice. This module encourages customers to perform repeated actions by rewarding them based on the level achieved during a predefined amount of time. The configuration of Tiered campaigns comes with a wide range of custom triggers for events and transactions, product-specific settings and a grace period after the campaign ends.

• The Aggregated customer attribute workflow node has been introduced to assist the identification of misusage or abuse of the loyalty scheme so that preventive actions can be taken in time (eg. canceling the registration of an event, sending a notification to the customer about the terms of use).

• The Entity lookup workflow node has been extended with a new option that enables the transportation of the attributes of a pending event through a workflow.

• There is a new module called Webhooks (beta). This comes with a new Webhook message (beta) workflow node that shows a dropdown from which you can pick previously saved trusted sites.
  Compared to the Webhook message node that requires typing in the details of the authentication, the new node makes sending workflow-generated webhooks quicker and easier.

Multi-accounts

• Validation and cross-check mechanisms have been implemented to ensure the compatibility of the Multi-accounts module with the Checkout accept module and the refund procedure. The newly introduced mechanisms provide a smooth transition between the stages of the transaction lifecycle.

• The default account configuration is now a mandatory setting of the Multi-account module. If the account property of an event is empty, the default account is automatically assigned, or events that have a Transaction ID inherit the account of the checkout event with the same Transaction ID.
  Events sent with the same Transaction ID of the checkout event but with different account property, the event will be rejected due to mismatch.

• Reward_revoke and reward_unbid events must have the same account property value as the preliminary reward and reward_bid events, respectively.
  If the account value is different, the revoke and unbid events will be rejected and if empty, the account property will be automatically populated with the account of the preliminary event.

Platform change

• A default value is available for Custom entities and Custom events. When creating or editing a custom field, there is a Default value opportunity for the following field types: string, numeric, boolean and URL.

API changes

• /customers/-/eventsis a new endpoint like the customer events endpoint that returns all events in the platform with their associated customer_id.

• It is now possible to query customers using the updated_at field at the /customers endpoint.

• Offers can now be accessed via the Entities API. An example response has been provided here.

• New navigation options have been introduced in the Workflows module. The Log and Running workflows pages are directly available from the workflow list, and clicking the name of the workflows opens up the workflow editor.

• A new unit_burn attribute has been added to the Events and Transactions collections. This makes it possible to store burned points on an individual product level instead of storing them for multiple items at the checkout.

• There is a new ‘Email Settings’ tab under the brand's Settings page.
  This enables choosing the transport type from which the platform-generated emails are sent out to Backoffice users. Besides the default setting, there are two extra options: Simple Mail Transfer Protocol (SMTP) and Amazon Web Services' Simple Email Service (AWS-SES).

• When opening previously executed exports, their description now shows the object name instead of the objectID.