Releases
Back to All

CDP | JFM '21

over 3 years ago by Sarth Talati

Detailed Release Notes!

There are some exciting features for card loyalty that you can check out.

The following are the key features of card loyalty.

  1. Create card linked loyalty program
  2. Import existing card data
  3. Generate physical cards
  4. Manage card requests using Member Care
  5. Integrate with POS or front-end using APIs

Card Linked Loyalty Program enables creating multiple loyalty cards within an Organization and linking card series with loyalty programs. Card Loyalty helps define different types of physical or digital cards based on pre-configured logic.:

The following functionalities are supported in Loyalty+ for Card Loyalty.

  • Issue cards to customers during or post-registration, where card numbers are added as customer identifiers.
  • Points allocation and redemption using card numbers (Loyalty Program).
  • Search customers by card numbers.
  • Delete or deactivate cards issued to customers.

Use Case

  1. Card-linked program based on the target audience
    • Create different cards and loyalty programs on the values of customer segments. For example, value cards, premium cards, and family cards.
  2. Card-linked program based on distribution mode
    • Create physical cards or digital cards based on customer preference and link them to one or more loyalty programs.
  3. Card-linked program based on Organization Units
    • Create card-linked loyalty programs for each organization unit.

Key Features of Card loyalty

I. Create Card linked loyalty program

  • Create a card series from InTouch Organization Settings.
  • Create a card series using APIs.
  • Create a card series using import. For details, see card series import.
  • Link card series with an existing loyalty program. For details, see create card-linked loyalty programs.

II. Import existing card data

Import historical data of customers’ card details. For details, see card import.

III. Generate physical cards

  • Generate cards from InTouch Organization Settings.
  • Generate card series using APIs.
  • Generate card series using import. For details, see card series import.

IV. Manage card requests using Member Care

  • Configure settings to issue cards from Member Care
  • Issue a new card to a customer. For details, see the issue card to a customer.
  • View card details of a customer
  • Search a customer using a card number
  • Update status of a card
  • View card status audit log

V. Integrate with POS or front-end using APIs

  • Register a customer with a card number. For details, see the API documentation v2 and v1.1.
  • Search customer by card number. For details, see the API documentation v2.
  • Issue card to an existing customer.
    • Issue a card number generated in Capillary [v2].
    • Issue a card number not generated in Capillary.
      • First, add a card number using v2/card API.
      • Then link the card number to the customer using v2/change identifier API.
    • Issue an instantly generated card number with a card series.
      • First, generate a card number using v2/card/generate API.
      • Then link the card number to the customer using v2/change identifier API.
  • Get card details of a customer.
    • Get card details using card number [v2].
    • Get card details using other identifiers [v2] and [v1.1].
  • Update card status [v2].
    • Deactivate a card.
    • Reactivate a card.
    • Expire a card.
    • Delete a card.
  • Add a transaction with a card number [v2] and [v1.1].
  • Redeem points and coupons with a card number.
    • Check if points are redeemable [v1.1].
    • Redeem points [v1.1].
    • Check if the coupon is redeemable [v1.1].
    • Redeem coupon [v1.1].

📘

For detailed release notes, see Card Linked Loyalty Program Release Notes (It is an internal document and can be accessed only by Capillary users).

Upcoming Features

  • Card based reports
  • Create audience lists using card data
  • Export card data

Limits on Creating Entities (Custom fields, Store entities, Payment modes...)

In this release, we are rolling out limits on the creation of the following entities in phases.

  • Custom fields
  • Store entities
  • Product Attributes
  • Payment mode attributes
  • Sharingan apps
  • Behavioral events
  • OAuth API clients

A list of such entities, their default limits, and release timelines can be found below.

Purpose

Capping is important to ensure fair usage of the platform features, achieve high system availability, and keep a check on the cost, as the higher number of entities have higher cost implementations at our end.

The following table provides a detailed cap for each entity.

  <th style={{ textAlign: "left" }}>
    Entity
  </th>

  <th style={{ textAlign: "left" }}>
    Limit
  </th>
</tr>

  <td style={{ textAlign: "left" }}>
    Loyalty registration custom fields
  </td>

  <td style={{ textAlign: "left" }}>
    30
  </td>
</tr>

<tr>
  <td style={{ textAlign: "left" }}>

  </td>

  <td style={{ textAlign: "left" }}>
    Loyalty transaction custom fields
  </td>

  <td style={{ textAlign: "left" }}>
    30
  </td>
</tr>

<tr>
  <td style={{ textAlign: "left" }}>

  </td>

  <td style={{ textAlign: "left" }}>
    Store custom fields
  </td>

  <td style={{ textAlign: "left" }}>
    30
  </td>
</tr>

<tr>
  <td style={{ textAlign: "left" }}>
    Product data model
  </td>

  <td style={{ textAlign: "left" }}>
    Product categories
  </td>

  <td style={{ textAlign: "left" }}>
    50
  </td>
</tr>

<tr>
  <td style={{ textAlign: "left" }}>

  </td>

  <td style={{ textAlign: "left" }}>
    Product brands
  </td>

  <td style={{ textAlign: "left" }}>
    50
  </td>
</tr>

<tr>
  <td style={{ textAlign: "left" }}>

  </td>

  <td style={{ textAlign: "left" }}>
    Product Attributes
  </td>

  <td style={{ textAlign: "left" }}>
    30
  </td>
</tr>

<tr>
  <td style={{ textAlign: "left" }}>
    Payment modes
  </td>

  <td style={{ textAlign: "left" }}>
    Payment mode attributes
  </td>

  <td style={{ textAlign: "left" }}>
    10
  </td>
</tr>

<tr>
  <td style={{ textAlign: "left" }}>
    Sharingan apps
  </td>

  <td style={{ textAlign: "left" }}>
    Active Sharingan apps
  </td>

  <td style={{ textAlign: "left" }}>
    100
  </td>
</tr>

<tr>
  <td style={{ textAlign: "left" }}>
    Behavioral events
  </td>

  <td style={{ textAlign: "left" }}>
    Behavioral events
  </td>

  <td style={{ textAlign: "left" }}>
    20
  </td>
</tr>

<tr>
  <td style={{ textAlign: "left" }}>

  </td>

  <td style={{ textAlign: "left" }}>
    Behavioral events for Loyalty+ Destination
  </td>

  <td style={{ textAlign: "left" }}>
    10
  </td>
</tr>

<tr>
  <td style={{ textAlign: "left" }}>

  </td>

  <td style={{ textAlign: "left" }}>
    Attributes in a Behavioral event
  </td>

  <td style={{ textAlign: "left" }}>
    20
  </td>
</tr>

<tr>
  <td style={{ textAlign: "left" }}>
    Store data model
  </td>

  <td style={{ textAlign: "left" }}>
    Stores
  </td>

  <td style={{ textAlign: "left" }}>
    500
  </td>
</tr>

<tr>
  <td style={{ textAlign: "left" }}>

  </td>

  <td style={{ textAlign: "left" }}>
    Tills per store
  </td>

  <td style={{ textAlign: "left" }}>
    20
  </td>
</tr>

<tr>
  <td style={{ textAlign: "left" }}>

  </td>

  <td style={{ textAlign: "left" }}>
    Zones per org
  </td>

  <td style={{ textAlign: "left" }}>
    30
  </td>
</tr>

<tr>
  <td style={{ textAlign: "left" }}>

  </td>

  <td style={{ textAlign: "left" }}>
    Concepts per org
  </td>

  <td style={{ textAlign: "left" }}>
    30
  </td>
</tr>

<tr>
  <td style={{ textAlign: "left" }}>
    OAuth API client
  </td>

  <td style={{ textAlign: "left" }}>
    API clients
  </td>

  <td style={{ textAlign: "left" }}>
    15
  </td>
</tr>
Module
Custom fields

What if an Org needs more entities of a type?

The limit is on the count of active entities. Firstly, check if there are any redundant entities added for a type and delete them. Orgs are charged for the usage.
If that does not suffice, raise a task ticket on JIRA with the component as 'API'. The request will go through an approval process, which will require the involvement of a Capillary PoC (Project Manager or Customer Success Manager) to explain the case. We will override the limit for the org.
The estimated turnaround time for these requests will be 5 working days.

📘

If agreed that an Org is not paying based on the usage, the updated pricing would be decided by CSM/Sales PoCs. The business teams collaborate with the Org to suggest subsequent actions.

Will existing Orgs that are overutilizing the limits be impacted?

Data capture will not be impacted due to this even if the entity limit is exceeded. So, if 50 custom fields are already active for an org and the limit is 30, it won't have any impact on the existing integrations or data import. However, the creation of new custom fields will be forbidden and errors will be thrown indicating a limit breach.
When the limit is exceeded, the imported record numbers' limitation will not allow any data ingestion. However, the limit on record imports is already fixed and can be increased if required. Using this feature, it is possible to set the limit on records at the Org level.

For specific brands that require higher import limits, such as CP All, the limit can be increased so that the FTP import gets executed without interruption.

📘

Currently, CP All is considered as an exception.