Get Tier Level Progress and Advance to Next Tier Based on Purchases
Obtains the tier level progress for a customer so they can understand how close they are to advancing to the next tier. The task then indicates the purchases necessary to generate sufficient points to satisfy the loyalty ruleset and advance the customer to the next tier. With this knowledge in mind, the customer can make requisite purchases they need to reach the next tier.
The SessionM platform plays an important role in this workflow, as it must manage the transaction job, notifying the customer that the job ran successfully, checking each purchase against the loyalty ruleset that governs any related point awards, and, finally, moving the customer to the next tier level when they've met the conditions stipulated in the loyalty ruleset.
These rules can be defined in an economy rule hierarchy governing a tier system. They provide an excellent means for controlling the conditions that govern when transactions can reward customers with specific loyalty outcomes. For more information, you can read further on configuring rules for tier-related behaviors.
Sequence Diagram
See the overall flow for this task below.
API Endpoints & Constraints
POST /api/2.0/send_transaction
If passing an external user ID to SessionM and using the "ext → internal translation pattern," an additional call to get the internal SessionM user ID is required and made.
Bear in mind the following limits:
- Maximum number of items is 1,000; maximum number of discounts is 100.
- Maximum number of payments is 100.
- Maximum number of custom object elements is 1000 (drops in orders of magnitude as the object complexity and size increases.
- Limit number of calls to the send transaction operation and make them only at the end of the transaction. However, changes and voids may be applied as needed.
- Similarly, offer locking and validation should be at the end of the transaction and not after each new item is added or removed.
- Return periods greater than 12 months will not be able to restore points upon returns.
- Avoid using the user ID translation pattern when possible. These APIs are agnostic of the user ID, which is the source of truth for the customer. It is just as viable to pass an external ID and NOT need to translate when using the SOR pattern, where the external user ID is treated as the SessionM ID for internal processing. Note: This only works when there is one source of external ID. Multiple sources of user ID would require translation (normalization) to SessionM user ID.