Skip to main content
If something isn’t working in the Store, find the symptom below.

Setup and Configuration

What you see: The Store, Product, Cart, or Cart Indicator component reports that it cannot load its settings.Why: Every Store component resolves a Store Settings record by name from its Store Settings property, which defaults to Default. No such record ships with the package, so a fresh org has nothing to resolve — and a typo or a renamed record breaks it the same way.Fix: Create a Store Settings record (naming it Default matches the property default), or correct the property to an existing record’s name — not its label. See Setting Up Store Settings.
What you see: The shopper browses, adds items, reviews the cart, and only then gets an error on Continue.Why: Checkout Page URL is blank on the Store Settings record. Nothing earlier in the flow needs it, so the problem surfaces at the last step.Fix: Set Checkout Page URL to your payment checkout page, then walk the whole flow once as a shopper. See Setting Up Store Settings.
What you see: A validation error naming Cart Business Unit Id, Guest Bucket Account Id, or the placeholder Ids.Why: Three validation rules block combinations that would fail at runtime — Specific Id business-unit logic with no Id (or an Id that isn’t 15 or 18 characters), Bucket Account guest logic with no bucket Account, and guest checkout enabled with a placeholder Id missing.Fix: Fill in the field the error names, or change the picklist that made it required. See Setting Up Store Settings.
What you see: You expected a drawer and got a page, or the reverse.Why: Show Cart As on the Store Settings record decides this, not a property on the Cart Indicator. Drawer opens the slide-in panel; Page navigates to Cart Page URL.Fix: Change Show Cart As, and confirm the Cart Indicator points at the Store Settings record you edited. See The Cart.

Products Not Appearing

What you see: A product you expect to sell is missing from the grid, and its direct URL says it is unavailable.Why: The Store applies a strict eligibility test, and any one failure hides the product. The usual causes, roughly in order of how often they bite: Product Visibility is still Staff (the default on every new product); Product UUID is blank; there is no active price book entry on the standard price book; the product is inactive; it is a tax product; Used By FusionCore is unchecked; or its Business Unit is outside Product Business Unit Ids.Fix: Work down that list on the product record. The grid and the Product page share one test, so fixing it restores both. See Preparing Products for the Store.
What you see: Switching currency makes a product vanish.Why: On multi-currency orgs the Store only shows products with a price book entry in the selected currency. For subscription products the plan’s price books must line up with that currency too.Fix: Add price book entries in each currency listed in Currency ISO Codes, or drop the currency from that list.
What you see: Category pills don’t include a category whose products are on sale.Why: Product Category Visibility on the category is not Portal or Staff and Portal. Products stay purchasable — only the category is hidden, so shoppers can reach them by search but not by filter.Fix: Set Product Category Visibility on the FCORE_PAY__Product_Category__c record. See Preparing Products for the Store.
What you see: A few categories are inline and the rest are hidden behind More.Why: This is expected. Max Visible Category Pills on the Store component controls how many show inline on desktop; the default is 4 and the effective maximum is 8.Fix: Raise the property up to 8. A larger number silently falls back to 8.
What you see: Products are missing from a very large catalogue with no obvious pattern.Why: The Store loads at most 1,000 eligible price book entries per request.Fix: Narrow the storefront with Product Business Unit Ids, split it into multiple stores with their own Store Settings records, or supply a custom Store Data Provider Class.

Prices

What you see: The amount at payment exceeds the cart subtotal.Why: Store prices are pre-tax. Tax is calculated at checkout, once there is an address to calculate against.Fix: Expected behavior. The cart shows estimated tax where it can, but the authoritative figure comes from checkout.
What you see: No struck-through list price and no Your Price.Why: Member pricing depends on who the shopper is. Guests get list pricing because there is no account or contact to qualify them. A logged-in member sees Your Price only where they actually qualify for a better price book.Fix: Confirm the shopper is logged in, and that a price book they qualify for prices that product below list. Where several qualify, the cheapest sets Your Price.
What you see: The tile’s price moves while the shopper is shopping.Why: Quantity-tier pricing is recalculated on the fly, so crossing a tier reprices the product immediately.Fix: Expected behavior — it keeps the displayed price honest.
What you see: A subscription sorts oddly against fixed-price products.Why: Price sorting uses the price shown on the tile. For a product whose price varies by subscription plan, that is one representative price, not the one the shopper may eventually choose.Fix: Expected behavior. Where it matters, avoid mixing plan-variable products into a price-sorted store view.

Cart

What you see: A guest returns and the cart is empty.Why: A guest’s cart lives in their browser’s local storage, not in Salesforce. Clearing site data, a private window, or a different device or browser all start from empty. No Order exists until they continue from the Cart page, so there is nothing to restore.Fix: Nothing to recover. Where losing carts matters, encourage sign-in — a member’s cart is a real Open Order and follows them everywhere.
What you see: The cart is cleared after a currency change.Why: Prices and product availability both depend on currency, so the cart cannot carry across. The shopper is warned and has to confirm before it happens.Fix: Expected behavior. Offer fewer currencies in Currency ISO Codes if shoppers switch by accident.
What you see: One add-to-cart produced multiple lines for the same product.Why: Max Quantity Per Item caps units per line item. Extra units spill onto additional lines, each capped at the same limit — ten units with a limit of four become 4, 4, and 2.Fix: Expected behavior. Raise or clear the field if you did not want lines split. Note it does not cap the total a shopper may buy.
What you see: The shopper can remove a line but not change its quantity.Why: The product’s Max Quantity Per Item is 1, so a quantity control would have nothing to do.Fix: Expected behavior — this is how subscription products are normally configured.
What you see: A member’s cart contains older items.Why: A member’s cart is a single Order in Open status, reused across sessions and devices. It persists until they check out or empty it.Fix: Expected behavior. The shopper can remove lines; the same Open Order is then reused rather than duplicated.
What you see: The Cart page reviews the cart but offers no way forward.Why: Hide Checkout Button is checked on the Cart component. It hides the step indicator and the guest identity section along with the button.Fix: Uncheck it unless you deliberately wanted a read-only cart. See The Cart.

Guest Checkout

What you see: The Cart page shows only Login / Create an account.Why: Continue as Guest User is unchecked on the Store Settings record. It is off by default.Fix: Check it, and set the placeholder Account and Contact Ids — a validation rule requires them together. See Guest Checkout.
What you see: Every guest purchase appears under one Account.Why: Either Guest Account Logic is Bucket Account, which is what that setting does, or you are seeing orders still on the placeholder Account because they never completed checkout.Fix: For per-buyer attribution use Individual Account, or enable Person Accounts. For orders stuck on the placeholder, those are abandoned checkouts, not resolved purchases.
What you see: You set Individual Account or Bucket Account and neither happens.Why: Person Accounts are enabled in the org, which overrides the setting — fusionCore creates a Person Account for the guest instead.Fix: Expected behavior. Person Accounts are usually the better home for an individual buyer.
What you see: Two Contacts for the same person, both flagged Guest Contact.Why: Guests are matched to an existing Contact by email. A different or mistyped address does not match, so a new Contact is created.Fix: Merge the duplicates. To match on something more reliable, implement FS_PORTAL_StoreContactMatcher and name it in Contact Matcher Class. Filter on Guest Contact (FS_PORTAL_Guest_Contact__c) to find storefront-created records.
What you see: The guest entered a new address and the Contact still shows the old one.Why: A matched Contact’s existing field values are deliberately not overwritten. The address the guest typed goes onto the Order.Fix: Expected behavior. Update the Contact yourself if the new address should become their record of truth.
What you see: Continue reports the reCAPTCHA was not verified.Why: Validate reCAPTCHA For Guests is on and the challenge was not completed or did not validate.Fix: Have the shopper retry. If it fails consistently, check the org’s Google reCAPTCHA configuration. The challenge applies only to guests choosing Continue as Guest.
What you see: A guest’s checkout form has fewer fields than a member’s.Why: Guest orders hide the Account, Bill To Contact, and Notification Email fields. They are resolved from what the guest enters, so exposing them would invite edits in the wrong direction. The guest’s email is used for notification behind the scenes.Fix: Expected behavior. Collect anything extra you need through Additional Details Field Set.