Troubleshoot a Moola Redemption Issue
At a glance
Most Moola redemption issues trace back to three patterns: the team member's balance dropped the moment they submitted a redemption request (not when it was approved), a pending redemption is waiting on a leader who has not yet approved or rejected, or a Moola Store item is hidden by a launch date, expiration date, quantity cap, or active/inactive flag. This article walks the ten most common causes in order of frequency, with the fix for each.
Before you start
- Open the Moola Transaction Log from Team > Moola Transaction Log (Manager permission or higher required to view). Most redemption causes are visible in the log.
- Have the team member's profile available. The Moola tab on their profile shows their balance, transaction history, and any pending redemption.
- Know which Moola Store item is involved. Item configuration (launch date, expiration, quantity, active flag, Limited to Employees) drives most visibility-related issues.
Troubleshooting
Cause 1: The team member's balance dropped but they have not received the reward
This is the single most common redemption report. The balance deducts immediately when the team member submits the redemption request, not when the leader approves it. The ledger holds the amount pending approval, the leader still needs to approve, and the store still needs to hand over the reward.
Fix. Open the Moola Transaction Log. Find the pending redemption in the team member's name. If it is pending, a leader needs to approve or reject it. If it was approved, fulfillment is happening through the store (not through OneClick); check with whoever distributes rewards at your store. If it was rejected, the Moola credits back to the balance (see Cause 6 if the credit-back did not happen).
Cause 2: A redemption has been pending too long
Redemption requests sit in the Moola Transaction Log until a leader approves or rejects. If the assigned leader is out, on vacation, or simply missed the notification, the redemption can sit indefinitely.
Fix. Open the Moola Transaction Log. Find the pending redemption. Any Manager or above can approve or reject from the same view; you do not have to wait for the originally-assigned leader if the delay is unreasonable. If the store's culture needs a specific leader to sign off, message that leader through Chat to get eyes on the request.
Cause 3: A team member cannot see an item they expected to see
Moola Store items have several visibility controls. Any one of them can hide an item from a team member who expects to see it.
Fix. Open the Moola Store item in its configuration view (Settings > Moola > Store or equivalent). Check in order:
- Launch date. The item is hidden until the launch date arrives. If the date is in the future, team members cannot see it yet.
- Expiration date. The item is hidden after the expiration date. If the date has passed, the item is no longer available.
- Active flag. The item may have been Deactivated. Activate it to restore visibility.
- Quantity. The item may be sold out. Quantity counts down as redemptions are approved; when it hits zero, the item is hidden until the store sets a new quantity.
- Max per employee. The team member may have already hit their personal cap for this item. Check their redemption history on the Moola tab of their profile.
- Limited to Employees. The item may be restricted to a specific list of employees that does not include the team member. If the list is set, only those named can see the item.
Cause 4: A leader did not get a redemption notification
By default, Manager permission and above receive Moola Redemption Requested notifications. If a different leader is expected to see redemptions for a specific item (for example, the team member who physically owns the inventory for branded shirts), the item needs a distribution owner configured explicitly.
Fix. Open the Moola Store item. Set the Leader in Charge of Distribution to the specific leader. Add additional notification recipients through the Select Team Members field if more than one person should be alerted. Confirm that each recipient has the Moola Redemption Requested notification enabled under their own notification settings (some roles can disable individual notification types).
Cause 5: A team member did not get an approval or rejection notification
When a leader approves a redemption, the team member receives a Moola Redemption Approved notification. Rejections surface through the transaction history as a credited-back entry but do not currently fire a dedicated rejection notification.
Fix. Confirm the team member has notifications enabled for their account (in-app and push). If in-app notifications are missing, the team member may have disabled the Moola category; ask them to open Settings > Notifications and re-enable. If the rejection happened but the team member does not realize it, point them to the Moola tab on their profile where the credited-back transaction appears in the history.
Cause 6: A rejection did not credit the Moola back
When a leader rejects a redemption, the Moola automatically credits back to the team member's balance. If the balance did not change after a rejection, something went wrong in the ledger.
Fix. Open the Moola Transaction Log and find the rejected redemption. Confirm the status is Rejected (not Approved or still Pending). If the status is Rejected but no credit-back transaction appears in the team member's history, submit a support ticket with the team member's name, the redemption item, the rejection timestamp, and a screenshot of the Moola Transaction Log. This is a ledger inconsistency and needs support investigation.
Cause 7: A team member has enough Moola but the purchase fails
The team member clicks Buy on an item, has enough Moola, but the transaction does not go through or an error appears.
Fix. Check three things. One, the item's Limited to Employees field may restrict the item to a specific list that excludes this team member. Two, the item's Max per Employee cap may have been reached for this team member. Three, the item may have been Deactivated between when the team member saw it and when they clicked Buy. Any of the three will prevent the purchase. If none apply, have the team member close and reopen the app to clear any client-side cache, then try again.
Cause 8: An item shows as "out of stock" when the store still has inventory
The quantity field in the Moola Store item is an OneClick counter, not a real-time inventory signal. OneClick decrements quantity as redemptions are approved; it does not know what the store has physically on hand.
Fix. Open the Moola Store item and update the quantity to reflect the current physical inventory. For items the store wants to offer indefinitely (store credit, gift cards), leave the quantity field blank to remove the cap entirely.
Cause 9: The wrong leader appears as the approver on a redemption
Approvers are captured at the moment of approval, not assigned ahead of time. If a Manager approves a redemption, the Manager's name records as the approver even if the item has a different distribution owner configured.
Fix. This is working as designed. The distribution owner receives the notification but any Manager or above can approve. If your store needs strict separation between notification and approval, document the norm internally; the product enforces notification routing but not approval restriction.
Cause 10: A team member's Moola Store is empty or showing no items
If the team member sees no items at all in the Moola Store, either the store has no items configured, or every item is hidden by a visibility control (launch date, active flag, quantity).
Fix. Open the Moola Store configuration. Confirm at least one item is active, past its launch date, before its expiration date, with quantity available or blank, and not Limited to Employees in a way that excludes this team member. If the store has zero items at all, see Build Your Moola Store for the creation workflow.
Video
Not planned. Diagnostic articles lean on text; a video would duplicate the causes list.
Common gotchas
A team member says their balance dropped unfairly because they expected it to hold until approval.
This is the expected behavior, not a bug. Explain the ledger model: submitting a redemption deducts immediately, rejections credit back automatically, approvals keep the deduction. The model prevents a team member from redeeming the same Moola twice by spamming requests before a leader can react. Point team members at Redeem Moola Through the Store for the canonical team-member-facing workflow.
A leader rejects a redemption to "test" the workflow and the team member gets a credit-back they are confused about.
Do not use real team members' accounts to test redemption workflows. Create a test team member if you need to try the approve-reject flow; using real accounts pollutes their transaction history and confuses them.
A team member transferred Moola to another team member by mistake instead of redeeming.
Transfers are not redemptions. Transfers move Moola peer-to-peer; redemptions submit purchases against the Moola Store. If a transfer was a mistake, the recipient can transfer the amount back with a note. If the team member meant to redeem but tapped Transfer by accident, walk them through the redemption flow: open the Moola Store (not another team member's profile), pick the item, tap Buy. See Redeem Moola Through the Store for the full team-member-facing workflow.
A redemption is Approved in OneClick but the reward never arrived.
OneClick approves the request; the store distributes the physical reward. A gap between approval and arrival is a store-side fulfillment issue, not a OneClick issue. Confirm with whoever handles distribution (the Leader in Charge of Distribution on the item, or the store's Moola coordinator) that the reward is on its way.
A Manager wants to reverse an Approved redemption because it was approved in error.
Approvals cannot be un-approved through the UI. The closest workaround is a Deduct Moola action to take the Moola back (with a clear note explaining the correction) plus a Reject-equivalent conversation with the team member. The cleanest prevention is double-checking before approval; post-approval reversals always feel ad hoc.
A team member says they never got approved but the transaction log shows approved.
Notification delivery is not guaranteed. In-app notifications are reliable; push notifications can be silenced by device settings. The transaction log is the source of truth. Point the team member to their own Moola tab where the approval shows in their history.
The Moola balance on a team member's profile does not match the Moola Transaction Log running total.
Sum the team member's transactions in the log (awards plus, deductions minus, transfers plus or minus depending on direction, approved redemptions minus, rejected-then-credited-back as net zero). If the running total does not equal the displayed balance, submit a support ticket with the team member's name, the date range, and a screenshot. Balance inconsistencies need support investigation.
Related articles
- Understand Moola (Reference) for the canonical Moola model and notification rules
- Award Moola to a Team Member (How-To Guides)
- Redeem Moola Through the Store (How-To Guides) for the team-member-facing redemption workflow that produces most of the support patterns this article covers
- Build Your Moola Store (How-To Guides) for item configuration including launch date, quantity, and distribution owner
- Set Moola Budgets (How-To Guides)
- Approve or Reject a Moola Redemption (How-To Guides)
- Transfer Moola to Another Team Member (How-To Guides)
- Deduct Moola from a Team Member (How-To Guides) for reversing an erroneous award
- Understand Notifications (Reference) for notification delivery and enablement
Still stuck
If a redemption is behaving in a way none of the ten causes explain, or if a ledger inconsistency appears (balance does not match the log, credit-back did not fire on rejection, approval did not trigger a notification despite settings being correct), submit a support ticket with:
- Your store number.
- The team member's name.
- The Moola Store item involved.
- The redemption timestamp and current status.
- A screenshot of the Moola Transaction Log showing the relevant rows.
- A screenshot of the team member's Moola tab on their profile.
- What you expected to happen versus what happened.
Support typically responds within one business day.
Pre-publish checklist
20 302303e4-863c-43bb-8419-f448fb69a9a3 complete Seven sections filled (Troubleshooting diagnostic-sequence pattern).
21 8d66a83c-9274-4c20-b082-97027de2504b complete Ten ordered causes, most common first (immediate-deduction at top).
22 0db9694a-3cea-415f-9efb-37d938387fc5 complete No em dashes, no hedge words.
23 39575e94-23fe-4ad0-b61d-631edde3de91 complete Permission-based role references throughout.
24 cf36c973-10c8-4d78-ab27-fc89a8601734 complete Voice: leader and team member, not operator.
25 e277317e-6191-49ef-912c-bb905ff2d916 complete No real team member names or store numbers.
26 73c314de-ece5-451e-82dd-f2005cacd3d8 complete Ledger model (immediate deduction, automatic credit-back) canonical with Understand Moola.
27 05fc76c5-6fa0-45f9-b126-77e92b2020b1 complete v2: Redeem Moola Through the Store added to Related list (Turn 53 incidental re-confirmation).
28 3c7521e2-e7f5-4bca-abe2-abcb61d3bcb3 incomplete UI verified against Production.
29 f9de3951-656a-4128-89b2-84dadc98f91b incomplete Reviewed by Jared and Kevin.
Why this article exists
Surfaced by the Wave 1 cross-link map Pass 2 audit (Turn 38, Flag 38). Understand Moola references this article as a placeholder in its Related list. Redemption troubleshooting is one of the highest-frequency support-ticket patterns in the Moola module: "my balance dropped," "my redemption is stuck," "I cannot see the item I want," "approval took forever." Ten-cause diagnostic sequence deflects the common patterns. With this article drafted, the Moola module is complete on its Pass 2 Related-list commitments and Flag 38 is closed on the drafting side (Add a Team Member remains separately blocked under Flag 25).
Source
Derived from Understand Moola v1 (395575424) for the request-and-approval ledger model, immediate-deduction behavior, credit-back-on-rejection rule, notification routing defaults, and Moola Store item configuration surface. No new VERIFY blocks. v2 cross-link enrichment (Turn 53) sourced from Redeem Moola Through the Store v1 (396951589) which had this article in its Related list as a forward reference; the Turn 53 update makes the link bidirectional.