Explanation

When a promotional reward is expected but not issued after a qualifying transaction, the issue is almost always traced back to either the promotion's setup (record configuration) or the automation process (Flow) responsible for triggering the reward issuance. Since the purchase transaction (the coat) exists, the Administrator must verify that the promotion is correctly defined and active, and that the automated process to issue the resulting vouchers is functioning properly.

✅ Correct Option: A & C

A. That the promotion has been created with the characteristics, correct dates, and the associated Voucher Definition.
The Promotion record itself must be correctly configured to be processed.
Correct Dates: The promotion must be Active during the time the coat was purchased (winter).
Associated Voucher Definition: The promotion record must be correctly linked to the Voucher Definition for the "hat and gloves." If this link is missing or incorrect, the system won't know what to issue, leading to missing vouchers.

C. That the flow is active and has been created to apply the promotion.
In Loyalty Management, transactional events (like a coat purchase creating a Transaction Journal record) typically require a Flow (automation) to detect the event and call the necessary Loyalty Management action. This Flow must be Active and configured to run the Process Promotion action, which evaluates the transaction against the active promotions and issues the voucher if the criteria are met. If the Flow is inactive or flawed, the voucher issuance fails.

❌ Incorrect Options

B. That the promotion has specified the Current Liability Amount.
The Current Liability Amount is a financial and accounting field used to estimate the value of unredeemed rewards for liability tracking. It is purely informational for finance and reporting and plays no part in the operational mechanics of issuing a voucher. Its absence or incorrect value would not prevent a voucher from being created upon a qualifying purchase.

D. That the member is a campaign member of the promotion campaign.
Loyalty Management promotions that are triggered by a transactional event (like buying a coat) do not typically require the loyalty member to be a Campaign Member of a standard Salesforce Campaign record. The promotion criteria are evaluated directly against the transaction data and the member's status within the Loyalty Program. Checking Campaign Membership is an unnecessary step for this specific scenario.

🔗 Reference
Salesforce Help: Create a Promotion (Details the need to link the Voucher Definition and set correct start/end dates.)
Salesforce Help: Create a Flow to Apply a Promotion (Details the mandatory use of automation to trigger the voucher issuance process based on a transaction.)

Explanation:

When adding a new partner to a Salesforce Loyalty Program, the Administrator must link the partner to the program via the partner’s business account, not individual contacts. The partner type determines if the partner can both accrue points and redeem rewards. Proper setup ensures that loyalty transactions are correctly tracked for the partner and integrated into the program’s accrual/redemption processes.

Correct Option:

✅ A. Enter the program partner name > Associate to an account > Set program partner type to ‘Both’ (Accrual and Redemption)
Program partner name → Provides a unique identifier for the partner in the loyalty program.
Associate to an account → Links the partner to the correct business entity, which is required for accrual/redemption tracking.
Set partner type to ‘Both’ → Enables the partner to both accrue and redeem points, fulfilling the strategic partnership objective.
This sequence follows Salesforce’s recommended method for adding partners to loyalty programs.

Incorrect Options:

❌ B. Enter the partner contact name > Associate to a partner Contact Name > Set program type to ‘Both’
Incorrect because loyalty program partners are business entities, not individual contacts.
Associating a contact instead of an account will not allow points accrual or redemption at the organizational level.
Using a contact can break integration with transaction processing and reporting.

❌ C. Enter the program partner name > Associate to a Partner Contact Name > Set program partner type to ‘Both’
Partially correct with the program partner name, but linking to a contact is invalid.
Partner accounts, not contacts, must be associated to track business-level loyalty activity.
Contact association does not support accrual or redemption flows.

❌ D. Choose relevant account name to Associate to the program > Set program partner type to ‘Both’
Missing the step to enter the program partner name, which is required to create a new partner record.
Only selecting an existing account is insufficient for adding a new partner.
Without a program partner name, the system cannot uniquely identify the new partner in the loyalty program.

Summary:
To add a new partner, the Administrator must enter the partner name, associate it with an account, and set the partner type to ‘Both’. Contacts alone cannot be used, and skipping the partner name will prevent creation.

Reference:
Salesforce Help — Add a Partner to a Loyalty Program

Explanation:

For this scenario, the retailer needs to track when a member's last activity occurred to expire their points. The Qualifying Points currency is the correct choice because it is designed to impact a member's tier status, which is often tied to activity-based rules. The 'Activity Model' for points expiration is the precise method to achieve this. This model links point expiration to a member's last activity, such as a purchase or redemption, making it ideal for the requirement of expiring points after 18 months of inactivity. This approach encourages members to remain engaged.

Incorrect Option:

🔴 A. Set up a Non-Qualifying Points currency and apply the expiration model 'Fixed Model':
Non-Qualifying Points do not affect a member's tier status, and the requirement is to use a method that encourages members to return to purchase and redeem their points, which can be linked to tiers. The 'Fixed Model' expires points on a specific date, not based on member activity. This would not meet the requirement of expiring points after 18 months of inactivity.

🔴 C. Set up a Non-Qualifying Points currency, apply the expiration model 'Activity Model':
This option incorrectly uses Non-Qualifying Points. While the 'Activity Model' is the correct expiration method, using Non-Qualifying Points is not a best practice for a program that is trying to motivate members to maintain their tier status through activity. The program's core goal is to drive engagement, and Qualifying Points are better suited for this purpose.

🔴 D. Set up a Qualifying Points currency and apply the expiration model 'Fixed Model':
This option correctly uses Qualifying Points, but the expiration model is incorrect. The 'Fixed Model' would expire points on a specific, predetermined date, not based on the member's last activity. The retailer's requirement is to base the expiration on a rolling 18-month period of inactivity, which the 'Fixed Model' cannot support.

Summary:
The sports retailer wants to create urgency by expiring points if a member is inactive for 18 months. To achieve this, a Loyalty Consultant must configure the program to use a currency that tracks member engagement and a flexible expiration model. The best solution is to use Qualifying Points, as they are ideal for linking to tier status and member activity, and the Activity Model, which is specifically designed to expire points based on a member's last active date, perfectly meeting the 18-month inactivity requirement.

Reference:
Salesforce Help Documentation: Set Up a Points Expiration Model in Loyalty Management.

Explanation

Experiential loyalty programs emphasize tracking diverse member interactions like events, referrals, or social shares to personalize engagement. Best practice uses core objects for categorizing activities precisely without custom fields. Transaction Journal records all events, while Type and Subtype fields classify them (e.g., Accrual Type with Referral Subtype). This enables targeted processing, reporting, and rules, ensuring scalable activity insights for better member journeys.

Correct Option: C

✅ Transaction Journal Type and Subtype are picklist fields on the TransactionJournal object, designed to categorize activity types systematically.
• Type defines broad categories (e.g., Accrual, Redemption, Adjustment).
• Subtype adds granularity (e.g., Purchase, Social Media, Event Attendance).
• Supports loyalty program processes matching these for automated actions.
• Ideal for experiential programs to segment and analyze varied interactions efficiently.

Incorrect Option: A
❌ Loyalty Ledger tracks point balances and adjustments post-processing, not the originating activity type. Transaction Journal logs the event, but Ledger focuses on currency outcomes like credits/debits. Using these misses direct activity classification for design and reporting.

Incorrect Option: B
❌ Loyalty Member Currency stores aggregated balances per member and currency, summarizing totals rather than detailing activities. Paired with Transaction Journal, it overlooks type/subtype for precise tracking, limiting experiential personalization based on specific behaviors.

Incorrect Option: D
❌ Journal Type and Subtype are imprecise; the correct fields are specifically Transaction Journal Type and Subtype on the TransactionJournal object. Generic naming doesn't align with Salesforce schema, potentially causing setup errors or incomplete activity categorization.

Reference:
TransactionJournal

Explanation:

In this scenario, the customer is eligible for a compensation voucher because the t-shirt is out of stock. Salesforce Loyalty Management enables agents to issue vouchers directly to the customer, ensuring they can redeem it immediately. The voucher must reflect the correct discount value and validity period for proper compensation.

Correct Option:

✅ C. Use Issue voucher from the Loyalty Program Member page
Allows the agent to directly issue a voucher to a specific customer.
Ensures the voucher is linked to the Loyalty Program Member record.
Can configure a 50% discount with a one-year validity, making it immediately usable.
This is the standard Salesforce method for agent-issued, real-time vouchers.

Incorrect Options:

❌ A. Use the “issue Voucher” flow template
Flow templates are designed for automated or repeatable voucher issuance.
They are not ideal for one-off, real-time customer compensation, as the agent cannot control the immediate issuance.
Using a flow template would require additional steps to assign the voucher, delaying customer satisfaction.

❌ B. Activate the voucher assignment batch
Voucher assignment batches are intended for bulk processing of vouchers, typically scheduled for multiple members at once.
This method is not real-time; the customer would not immediately receive the 50% discount.
Relying on a batch could lead to frustration, as the compensation would be delayed until the batch runs.

❌ D. Assign a voucher definition from the customer’s Loyalty Program Member
Assigning a voucher definition only defines the type and parameters of the voucher (e.g., discount percentage, expiration).
It does not actually issue the voucher to the customer.
Without issuing, the customer cannot redeem the discount, so this step alone is insufficient.

Summary:
To ensure immediate compensation, agents must issue the voucher directly from the Loyalty Program Member page. Batch, template, or definition-only methods won’t provide instant access or usability for the customer.

Reference:
Salesforce Loyalty Management – Vouchers Overview