Storefront operator tasks

Goal

Keep the public storefront healthy day to day: publish the right catalog, process orders end-to-end, and fix checkout blockers — using the Merchant Dashboard (not by editing the shopper SPA).

Export filtered workspace records

Owners can export CSV from Orders, Pages, and an order’s Return requests. Exports use the current search/status/archive filters and optional creation dates in UTC. Each file contains at most 10,000 matching records; narrow the filters when the limit is exceeded. Pages export translated metadata, not authored page bodies. Request exports contain the current order only. Downloads require a fresh authorized request and do not create a reusable public file. Spreadsheet formulas are escaped.

Review payment discrepancies

In Reconciliation, compare the expected gateway amount with the captured amount. For gift-card or store-credit split payments, the expected gateway amount excludes stored value. A recorded capture with pending confirmation requires review; do not charge again merely because confirmation is delayed. Use the order payment history to check the original attempt. Legacy evidence gaps require operator review and do not authorize automatic payment or stock corrections.

Who it is for

Operations staff and store managers with commerce.orders.manage, commerce.publish, and/or commerce.manage. Shoppers browse Home / Products / Cart / Checkout; operators work in the merchant shell.

Preconditions

• Store status Published — live storefront under General (draft stores are not shoppable).
• At least one published listing (connected) or active product (standalone).
• Working Shipping methods and Payments modules for the markets you sell in.
• Connected stores: BlueMatrix catalog/pricing/stock sync healthy enough for reservation and order hand-off.

Steps — before traffic

1. General — confirm locales, tax display, guest checkout, inventory sync mode, fulfillment policy (Ship when paid / when available / Manual), domains. Customer auth offers live under store settings.auth.*: passkeys / magic link (defaults on); Google (auth.offer_google, default off — requires Commerce Google OAuth credentials and a stable API callback URI).
2. Theme / Pages / Photo library — homepage and content match the campaign.
3. Catalog — publish listings or activate products; set collections and visibility (public / hidden / catalog only).
4. View store — smoke-test browse → cart → checkout path on the public URL.

Steps — order operations

1. Open Orders; filter by payment / fulfillment needs (dashboard To fulfill is a shortcut signal).
2. Open Order details — verify payment state, line items, addresses, and (connected) BlueMatrix sync / invoice linkage.
3. Fulfill per policy: mark dispatch / collect COD / handle failed delivery according to your payment module workflows.
4. Moderate Reviews when reviews are enabled.
5. On connected stores, check BlueMatrix sync for stuck orders, payment mismatches, listing coverage, outbox, and catalog sync issues.

Pack, ship and track an order

In Order details → Shipments, enter the quantities for the parcel and choose Allocate shipment. Unallocated quantities remain open. Choose Mark packed, then add manual tracking or purchase a carrier label. Dispatch shipment applies the store's fulfillment policy and required stock/invoice checks. Mark delivered finishes only that shipment. The order is fulfilled after all quantities arrive.

For failed delivery, enter an internal reason and choose Record failed delivery. Enter a new reason before Retry delivery. Cancel a parcel only before dispatch; a purchased carrier label must be resolved first. If a response is lost, use Retry same action, including after reload, rather than allocating again.

To buy labels, configure the provider/method and Shipping origin in Shipping. For a packed parcel choose a carrier method, enter weight in kg and dimensions in cm, and Get label quotes. Select the rate and Buy selected label. Open or reprint label reopens the same document. An unknown outcome requires Check existing label request; it does not permit another purchase. Request label refund needs a reason and remains pending until the carrier confirms the refund. Refresh carrier tracking checks a dispatched carrier parcel. Manual tracking remains available for shipping methods without labels.

Customers see shipment status and tracking through their account or signed order link. Internal notes and label documents are not included in that view.

Analytics, reports and operational alerts

Open the dashboard's Commerce analytics section and select the date range in the displayed store timezone. Sales are the accepted-order cohort: paid orders, partially collected orders and approved business terms. Refunds use settlement dates; collections use collection dates. Currencies are shown separately. Average order value uses gross order totals. Recovered revenue is an association with a recovered cart, not proof that a reminder caused a purchase. Product rows show ordered units before returns. Export the financial totals or the displayed page of products, operational exceptions or verified costs.

The shopping funnel counts distinct consented sessions created within the window, observed through its end. Paid conversions require a checkout-start event in the same session. Unconverted sessions may complete later. Optional events are retained for 90 days, so the funnel does not represent all visitors or older history. Customers choose Analytics preferences in the storefront footer. Account customers also control analytics in their verified account preferences. Declining never blocks shopping; withdrawal removes behavioral events and unlinks payment facts. Payment completion is recorded only by the server, separately from marketing.

Verified costs come from posted BOS invoices and credit notes, using frozen costs and document exchange rates through the report end. Missing evidence is Unknown. The report never treats missing costs as zero. Standalone orders without recorded cost evidence therefore have unknown margins.

Under Operational alerts, choose a condition, its threshold and an eligible merchant recipient. There are no enabled defaults. The job checks every five minutes and queues one message when a condition becomes active; it can notify again after resolution and recurrence. Connected recipients must retain BOS Commerce management or order-management permission. Use Refresh job status to inspect checks; delivery, uncertain outcomes and authorized retries appear in Messages. Removing a rule or revoking a recipient suppresses pending delivery.

Reorder reviews now ask for a current shipping method when the store has configured methods. Review the new charge and pickup location before creating the cart. Final checkout still revalidates stock, shipping and prices.

Business tax certificates

In Business accounts → Assigned catalog, an owner can record a verified certificate, country, tax class and validity dates. Save with a reason. Only active, verified buyers in an approved business receive the exemption, and only for the matching country/class during those dates in the store timezone (UTC if unset). Suspension, membership revocation or expiry removes it from new quotes. Existing orders retain their accepted tax amounts. Business approval and a tax number alone do not grant exemption. Connected stores display the assigned customer's configured BOS certificate metadata; manage those certificates in BOS. Checkout uses BOS tax determination rather than a Commerce exemption override.

Configure branch pickup

For a connected store, open Shipping → Method settings, choose pickup and enable Branch pickup location. Select an active BOS terminal and its warehouse, then enter the collection address, timezone, opening hours, preparation time, collection window and permitted payment methods. Add customer instructions in each store language. The location must have an opening period long enough for the collection window.

Customers see the address, hours and next collection window while choosing shipping. Checkout checks stock in that branch and registers pickup at the selected terminal. Changing the configuration requires a fresh shipping quote; existing orders retain the location promised at checkout. Closed terminals cannot accept new pickups. Catalog stock uses the best single eligible warehouse, without adding branch stock together. Location changes queue a retryable search refresh.

Orders on approved business payment terms can be prepared and handed over without marking them paid. Connected orders still require their synced invoice and POS order. A return against these orders preserves the outstanding debt until its approved credit or collection is recorded.

Prepare and hand over a pickup

Open Order details → Store pickup and choose Mark ready for pickup after checking the goods. The order must be paid or have approved business payment terms, and stock must be available; connected orders also need a synced invoice and registered POS order. Readiness sends a branded email with the customer's signed order link. A failed email remains visible and can be reviewed in Messages. Confirm the transport did not accept it before queuing a retry.

Check the recipient and order confirmation, enter the recipient name and a verification note, then choose Confirm handover. This records delivery without another sale or payment. If confirmation is pending, use Retry same handover action, including after reload. Reconcile POS handover checks handovers made at POS; scheduled reconciliation also updates the order. Customers see readiness and pickup completion, never the internal verification note.

Return requests and refunds

Customers request returns or cancellation from their account order or signed guest link. Configure Cancellation and return policy in Settings. In order details, approve or reject with a reason, confirm receipt, inspect each line, then apply stock disposition. Receiving goods does not restock them; damaged goods remain outside sellable stock. Use Retry same request action for a pending operation.

Under Refunds, select quantities and any shipping value, then Review refund value. The review shows net value, tax and allocated discount. Recorded external refund requires a reference and confirmation that funds were already returned; it does not call a payment gateway. Stripe refund submits against the original captured payment. Pending or uncertain refunds reserve their value until resolved. Use Reconcile recorded refund to check the existing result. If BOS confirmation is pending after funds were returned, retry accounting without paying again. Customers see refund status in their order and receive status email. The breakdown separates cash, value restored to the original gift/credit balance, and credit against unpaid business debt. A debt credit reduces the amount owed; it does not create spendable stored value or send cash.

For a paid cancellation, record or execute the refund first and confirm any BOS accounting retry. Then approve the cancellation request after verifying the goods have not shipped. Committed stock returns once. Connected cancellation also credits any unpaid invoice balance without another payout. A pending remote confirmation uses the same retry action; do not create a replacement cancellation.

Cash collections and receipt retries

In Order details, record each cash collection separately. If partial collections are enabled, enter the amount received now, not the total received so far. The remaining balance decreases after each accepted collection. Collecting cash does not mark the goods delivered.

For connected orders, each collection shows its BOS receipt status. Receipt needs retry means the cash is recorded but the receipt is not yet confirmed. Use Retry receipt sync on that collection; do not enter the same cash as a new collection. An owner or order manager can retry. Receipt synchronization uses the original amount and retry key, including after a timeout. Confirm the cash account and BOS connection configuration if repeated retries remain pending.

Payment history and unresolved payments

Open an order and use Payment history to review every recorded attempt, provider reference, test/live mode, amount and outcome. Use Next and Previous for older attempts. If loading fails, Reload retries the list.

Owners and order managers can choose Check with provider for Stripe, Lahza and saved-card payments. This checks the existing transaction; it never creates a charge. If the reference was lost, enter it from your provider dashboard. A wrong reference cannot authorize capture. Viewers can read history but cannot reconcile.

An Outcome unknown payment must be checked before another payment starts. A mismatched or additional capture is flagged for reconciliation. Review additional funds with the provider; the status check does not refund them. Saved cards require a verified customer email. Only Single provider routing is currently accepted.

Store credit

Open Store credit and balances to issue credit to a customer with a reason. Only owners can issue credit; viewers can read balances and history. If the reply is lost, use Retry recorded credit to recover the same issuance.

Verified customers can view balances in their account and choose a credit amount at checkout. Credit is held while payment is pending. An online method collects only the remainder; a credit-only order needs no gateway charge. A failed payment releases the hold. A new attempt checks that the credit is still available.

Refund review separates cash from the amount restored to original credit. Return only the displayed cash portion outside Commerce when recording an external refund. Choose Original stored value only when no cash needs returning. If credit restoration is pending, reconcile that refund; do not return the cash again. For a connected store, choose a verified customer to read the shared BOS/POS balance. To issue credit, select an open customer credit note in the store currency. The note funds the new balance; issuing credit does not record a cash payment. BOS and POS respect checkout holds, and refunds restore the original credit. If BOS confirmation is pending, retry the recorded action or use the reconciliation monitor. Gift-card purchasing and loyalty remain separate workflows.

Gift cards

Owners can enable gift-card purchases and set the number of days until expiry in Gift cards. Customers buy a card from the storefront Gift cards page and enter the recipient email. The recipient receives the code only after payment is verified. A connected card also waits for BOS funding confirmation. Cash on delivery is unavailable for gift-card purchases.

Owners can issue funded cards with a reason, review balances and reserved amounts, and open movement history. Connected issuance requires the bank or cash account that received the funding. Copy a newly issued or replaced code securely; it is masked and cleared when leaving. Disabling a card preserves its balance. Replacing a code invalidates the old code. Resolve pending redemptions before either action.

Customers can check a code and apply part of its available balance at checkout. The remaining amount uses an eligible online payment method. Failed payments release the hold; refunds restore the original gift-card allocation. Connected cards share the BOS/POS balance. POS redemption requires an internet connection.

Refunding the card purchase first reserves its unspent value. A purchase cannot be fully refunded after part of that value has been spent. Resolve that situation through refund review. If cash was refunded but BOS reconciliation is pending, retry the recorded refund; do not send the cash again. Delivery history records mail transport acceptance, which does not prove arrival in the recipient inbox.

Loyalty points

Open Loyalty points to configure earning per currency unit, redemption value, minimum spend, minimum points, product exclusions, the redemption percentage limit, and expiry. Choose whether points qualify when payment is confirmed or fulfillment is complete. A blank expiry means no expiry. Changes apply to new orders; existing orders retain their original rules. Saving requires a reason and management access.

Gift-card funding earns no points by default. Enable funding points explicitly if required, and choose separately whether merchandise paid with gift cards earns points. Enabling both allows points at both stages. Refunding the funded purchase reverses its proportional earned points.

Search for a customer to review available points and history. Authorized staff can add or subtract points with a reason. If a response is lost, retry the saved action; do not create another adjustment. Customers with verified accounts can view their own points history and apply points in either checkout layout. The current quote confirms the discount and limits before payment. Points require online checkout.

Unpaid orders reserve points. Confirmed failure or cancellation releases the hold; an uncertain payment retains it. Partial refunds restore the original redeemed points and reverse the corresponding earned points once. Restored points retain their original expiry. Already expired points remain unavailable. Reversing points already spent can leave a negative balance, which future earning offsets.

Business applications and assigned catalogs

Sign in with a verified email and open Business account to apply with your business name and billing address. An application does not grant credit. A merchant reviews it in Business accounts, records a reason, and approves or rejects it. Merchants can suspend an account and grant or revoke access for other verified customers in the same store.

Approved members can open their private catalog. In standalone stores, merchants assign published products, prices, minimum quantities, quantity increments and a minimum merchandise amount. Checkout rechecks these rules and saves the accepted prices. The minimum amount is measured before discounts, tax and shipping.

Connected stores use an authorized BOS customer and an explicit BOS price list. BOS controls the customer's credit limit and payment terms; changing the Commerce application cannot grant credit. Only products published publicly in this store appear in the buyer catalog. Suspended accounts lose business pricing eligibility.

Payment terms and business settlement

After approving an account, a standalone merchant can separately enable business credit, set a limit and enter the number of days until payment is due. Existing orders keep their original terms. Connected stores use the assigned BOS customer's credit policy. Approval alone never enables credit.

An eligible buyer can choose Pay on business account during checkout. The order remains unpaid, and its details show the due date and outstanding balance. Credit checks include existing debt and concurrent orders. Business credit cannot be combined with loyalty points, saved payments or stored value in this checkout.

Use Business account settlement on the merchant order to record collected funds. Partial payments reduce the balance; overpayments and different currencies are rejected. Connected settlement requires a current authorized BOS staff session and a settlement account. An interrupted response keeps the original operation for retry. Retry that operation instead of recording the payment again.

For a return, review the original line quantities and the split between outstanding debt and collected funds. Choose Credit outstanding business debt for a debt-only credit. If the review shows cash to return, use the manual refund workflow and record the actual external settlement. A debt credit creates no cash payment. Physical receipt and restocking still follow the return inspection workflow. Cancellation of an unshipped order restores committed stock once, after any collected funds have been refunded. Pending accounting must be reconciled before further collections. Suspending an account stops new business purchases without erasing debt.

Requesting and accepting quotations

Verified customers can open Account → Quotations and request an offer for the products and quantities in their cart, with a delivery address and message. Requests do not reserve stock. Customers can withdraw an unanswered or offered request with a reason.

Merchants open Quotations, enter each agreed unit price, choose delivery, set an expiry within 90 days and send their response. Each response is retained; a revised response replaces the active offer. Negotiated prices follow the store tax policy and cannot be combined with coupons or points discounts. Business catalog restrictions and minimum quantities and order amounts still apply.

The buyer reviews the total, expiry and delivery details, chooses a payment method or approved business terms, and accepts. Acceptance checks current stock, publication, delivery and taxes; changed totals require a revised offer. An expired offer cannot be accepted. Retrying the same acceptance opens the same order. Acceptance alone does not mark a payable order paid; complete payment from the order confirmation, or settle approved business terms through collections.

Connected offers create a native BOS quotation. Responding merchants need current BOS sales-management and Commerce-management access. Acceptance converts that quotation through BOS and uses the usual order synchronization history. Pending offers and acceptances can be reopened from Quotations and retried with their original details after a connection failure. If no order was created, a buyer can withdraw a pending acceptance with a reason; once an order exists, use the order cancellation workflow. Approved business terms reserve credit on conversion and remain unpaid until collection.

Online returns at POS

Open Online order returns from POS Returns or the register return sheet. Search by the full online order number, order ID, or exact customer email. A recalled Commerce pickup opens its original online order directly. Staff need POS and Commerce order permissions; refund execution additionally requires sales posting and receipt-management permissions.

Select quantities and a reason to request the return. Approve it, confirm the physical quantities received, and record a restock or write-off decision for each line. Complete the return after inspection. The original BOS return service owns the stock movement; the ordinary register refund action does not handle these online orders.

Review the refund against the original order lines and, when applicable, its return request. Select the original card capture, restore original stored value, or credit an outstanding business balance. For funds returned outside the system, enter their external reference and confirm they were actually returned; select the settlement account. Review the amount and cash, stored-value and debt portions before confirming. Physical return completion and refund settlement are separate recorded actions.

If confirmation is lost, use Retry original action or the pending record's retry control. Do not repeat an external payment. Return and refund histories are paginated; pending accounting remains visible until BOS confirms it. Orders keep the warehouse selected at checkout for retries, pickup registration and returns, even when the store default changes.

Exchanges and replacement orders

Approve the exchange and receive/inspect the returned items. The customer places a replacement through the normal storefront checkout, which uses current prices and reserves stock. In the original order's exchange record, search by replacement number or customer email and link the new order. Both orders must have the same customer, store, currency and operating context. The link is retained on retries.

In refund review, select the related exchange and refund its approved lines to the original tenders. Pay for the replacement separately. The exchange displays the replacement total minus the original refund: a positive amount is additional net payment; a negative amount is a net refund. It does not execute a net-only gateway charge or carry forward original prices. Manual refunds still require an actual external settlement reference. The customer can open the replacement from their original order's request history, including through signed guest access.

Complete the exchange after both settlements and any BOS accounting are confirmed. Completion applies the inspected stock disposition once. Pending accounting, missing refunds, unpaid replacements and stock exceptions block closure.

Fixed bundles and recommendations

Open Fixed bundles to choose each component and its exact variant, quantity per bundle, fixed selling price, storefront slug and publication status. Connected staff need Commerce, catalog and pricing management; changing publication also requires publishing permission. Standalone bundles use active component products or variants. Component stock determines availability; adjust component inventory, not the bundle parent. Connected bundles use existing BOS catalog and stock services.

Checkout freezes the component selection. A changed composition requires a fresh quote. Payment and inspected returns use the original quantities even after catalog edits; connected returns also retain the original component cost. Return a quantity of the sold bundle through the normal return workflow. Repeating receipt or payment processing does not repeat its stock movement. Bundle price and configured tax class feed the normal promotion, tax and refund calculation.

Retry an uncertain save with the same form. If BOS saved the bundle but its storefront slug conflicts, choose an unused slug. For a stale edit, reload the bundle and apply the intended changes to its current version before saving.

Open Product recommendations, select a product and add up to eight store listings. Move them into display order and save. Unpublished, archived or inactive standalone products are omitted from public recommendations. Existing BOS relations and recent products fill remaining places; collection/category suggestions remain available. Reload before overwriting a stale recommendation edit.

Buy again

From a paid order in your account or a valid guest order link, choose Review reorder. The review checks current publication, selected variants, prices and available stock, and marks changed line totals. An unavailable or archived item blocks the reorder; choose replacements from the catalog. Older orders from a previous operating mode require current catalog selection.

Choose Use these items in a new cart after reviewing the changes. This creates one new active cart and retains the previous cart. It does not charge or reserve stock. Previous coupons are not automatically applied; review delivery, promotions and the final quote during checkout. Verified connected customers keep their BOS customer pricing. A guest link does not grant another customer's pricing.

If the result is uncertain, choose Retry creating the same cart, including following a reload. A retry returns the same cart. After that cart has been purchased, start a new review for another purchase. Price changes require a fresh review.

Customer workspace and preferences

Open Customers to search names/email, filter verified accounts or internal tags, and browse all matching records. Registration-date pagination fixes an upper time boundary and excludes the current second; refresh to include newer registrations. Changing a search or sort starts a new result window. When sorting editable names or email, refresh after another staff member edits the sort field.

Open a customer for addresses, orders, returns/refunds, internal notes and tags. Only owners and order managers can add notes or change tags; a stale tag edit asks for a reload. Retrying a saved note preserves its operation. Notes and tags never appear in shopper account responses. Order history uses account association, not an unverified email match. The communication timeline records transport acceptance or failed attempts; acceptance does not prove inbox delivery or reading. Historical messages without recorded attempts are not invented.

Owners can export filtered customers directly as CSV, up to 10,000 rows. The export requires the active staff session, has no reusable download link, excludes notes/passwords/tokens, and neutralizes spreadsheet formulas. Narrow filters for larger datasets.

Customers choose marketing/recovery email and optional analytics separately under Account → Profile. No recorded preference means no permission. Granting requires verified email; withdrawal remains available without verification. Staff can read preferences but cannot grant them for the customer. A stale edit must reload; replay of an older grant cannot undo a later withdrawal. Essential order/payment/security notices are separate. These preference records do not themselves send campaigns.

Setup diagnostics

Owners can open Setup diagnostics and refresh the current store checks for payments, shipping, tax, domain, stock, branding, email and entitlements. The check reads configuration and recorded evidence; it does not initiate payments, labels, shipments or email. Connected entitlement reads use the store's server-side tenant. Service credentials and customer payment details are never displayed.

Read the columns separately: Supported means the runtime implementation is installed, Configured means the required saved values exist, Evidence verified means the described evidence exists, and Active means enabled with those prerequisites. An enabled setting can coexist with missing credentials or an unsupported provider. Checkout still evaluates the actual cart, destination and stock; this screen is not provider certification or proof of delivery.

Payment evidence requires a capture for the same store, method, account fingerprint and mode since the method was edited. Rotating the account invalidates that evidence. Carrier credential presence does not prove authentication, rates or label purchase. DNS evidence records ownership verification, not a new HTTPS/DNS probe. Stock movements prove recorded stock operations, not availability of every SKU. Preview branding in EN/AR and RTL. Log/array mailers, including fallback chains containing them, are not shown as delivery-ready; transport acceptance does not prove inbox delivery.

Standalone SKU usage and enforcement include products and variants; retrying an already-created variant does not consume another slot. Connected entitlement errors are visible and do not turn into an active entitlement. Standalone tax diagnostics now reflect active calculation rules, not the display preference. Owners open Tax rules to create inactive rules, review country/region, class, rate, inclusive pricing and priority, then activate them. The highest priority matching rule wins per class, then country/region specificity, then rule ID. Use standard for default products and shipping for delivery charges. Product-class assignment and customer exemption controls use paginated searches. Exemptions apply only to verified accounts; for inclusive prices they remove included tax. Rules do not claim fiscal-provider certification.

Cart and checkout request a current server quote. Changes to address, item selection, quantity, shipping or coupon invalidate it. Checkout rejects changed totals until the customer reviews a new quote. Connected pricing remains authoritative in BOS. Standalone line and shipping taxes round to the currency precision; the order saves its original quote for confirmation, customer/merchant details and refund allocation. Changing a tax rule does not recalculate an existing order. The displayed shipping amount includes shipping tax; the tax row includes that tax, so do not add it twice. Promotion controls are described below; bundles and final EC-07 acceptance remain unfinished.

Connected item and shipping tax use BOS tax codes, address/category rules and verified customer exemptions. Guessing a customer email does not grant their prices or exemptions. Accepted currency precision and tax components remain fixed when the order becomes an invoice or a refund, even after tax configuration changes. Partial shipping refunds retain their original tax allocation. Finish a pending refund and its BOS synchronization before creating another. A stale credit-note draft must be recreated; older invoices without a shipping snapshot require reconciliation.

Collections and automatic membership

Open Collections to search active or archived collections, page through results, and export up to 1,000 filtered rows. Exports require publication permission, protect spreadsheet cells and have no reusable public download link. Lists sort by position then ID; refresh after edits or concurrent catalog changes.

Create a translated name and unique URL slug, choose an optional parent, and save a draft or publish it. Parent and category pickers search all pages. Cycles and cross-store references are rejected. Saving an outdated editor asks you to reload. Archive hides the collection from its public URL, navigation, sitemap and search membership. Children retain their independent publication state. Restore keeps the collection as a draft. The editor asks before discarding unsaved changes.

For manual membership, search listings, choose one and save a position. Add, remove, or edit positions on later membership pages. Lower positions appear first in the default public collection order; equal positions use listing ID. Explicit shopper price/name filters retain their requested sorting. Merchant assignments survive BOS category synchronization.

For standalone stores, category rules select a manual collection. Create that collection and add/remove its listings using the same membership editor, then select it in the automatic rule. Archived categories match no listings. A referenced manual category cannot become automatic until its dependent rules are removed, preventing rule cycles. Connected category rules continue to use assigned storefront categories.

Connected merchant edits to collection names, URLs, positions, parents, rules and publication are now retained as explicit field overrides. Additions and removals also persist across BOS category or product publication sync, including removal followed by a later sync of the same category. Archive and draft restoration do not silently republish during synchronization. Existing historical edits without recorded ownership cannot be inferred; the release backfill review must identify any legacy exceptions.

Automatic collections accept up to eight conditions, matching all or any: assigned storefront category; exact listing badge/tag; guest catalog price at least or at most a decimal amount in store currency; and in-stock/out-of-stock. Update listing tags through the picker; merchant tag overrides survive BOS content sync. Price rules use the standalone listing price or the connected stored catalog price. Connected stock uses the tenant-bound BOS connector and configured store warehouse. An unavailable price does not match a price rule.

Changing rules replaces membership. The scheduled evaluator runs every minute, checking at most 100 collections and 25 listings per collection per invocation. Evaluate next 25 listings resumes the same scan manually. Membership updates incrementally; the last-complete timestamp changes after the scan reaches the end. A failed connector request keeps the previous confirmed membership, records an error and retries the same batch. Fix the connection or rule dependency, then resume. Large catalogs need multiple invocations. Checkout always validates current stock and price independently of collection membership. Operators must run the existing Commerce scheduler; the command is commerce:collections:refresh --limit=100.

Catalog import, export and bulk changes

Open Catalog import and export. Download the CSV headers or export a filtered standalone catalog (up to 1,000 product and variant rows). Downloads require catalog management permission and are generated for the authenticated store without a public file link. Spreadsheet-sensitive text gets a leading apostrophe; review those cells before reimporting. Connected product masters are exported from BOS.

Upload UTF-8 CSV up to 1 MiB and 1,000 rows. Use product or variant, create or update, and a unique SKU per row. Put a new parent product before its variants; define translated option values on the product before importing its option JSON. Blank product price preserves the price; blank variant price inherits. A supplied blank list price clears it, while an omitted price column preserves existing values. Blank publication preserves its state. Stock is an absolute on-hand quantity and cannot fall below active checkout reservations. Updates preserve other languages.

Review Preview import, row values and errors, then Confirm and apply next 25 rows. Repeat until no ready rows remain. Each row commits independently; errors do not turn into success. Reload history after interruption. Retrying the same file or batch preserves applied rows. Resolve failed-row dependencies before retrying; correct invalid rows or stale previews in a new file. Changed products, variants, stock balances or publication since preview require a fresh preview.

For bulk changes, enter standalone SKUs one per line and choose price, publish, unpublish, archive or restore. The same preview and row results apply. Archive hides new purchases and retains inventory/history; restore does not automatically publish. When archiving both a parent and its variants in CSV, place variant rows first: archiving the parent also unpublishes its variant listings.

Connected CSV also supports listing,update rows using listing_id from the listing export. Edit translated titles/body, slug, visibility, featured flag, JSON-array tags, publication and active/archived status. Blank body preserves existing text. Master prices and stock are rejected. Select connected listings with the paginated search for bulk publish, unpublish, archive, restore, feature or tag changes. Content changes remain merchant overrides during BOS sync. Restore always leaves an archived listing unpublished. Changed listing content since preview requires a new preview.

Connected CSV accepts draft,create rows with proposed SKU and EN/AR names. Applying submits the existing BOS approval request; it does not create connected products, set master prices or change stock. Approved products arrive through the normal BOS catalog synchronization.

Standalone variants

Open Products → Product variants. Define option codes and translated values, then create a variant with a store-unique SKU, translated name, optional price/list price, stock quantity/reason, and unique listing slug. Blank prices inherit the product; editing the product no longer overwrites variant price overrides. A saved creation can be retried after a lost response without creating another SKU or stock movement. Variant SKUs count toward the merchant catalog allowance.

Choose the default variant and explicitly publish its listing. The shopper's selected variant controls cart price, checkout price, and stock reservation. Stock adjustments cannot go below live reservations. Archive hides new purchases but preserves order and inventory history. Restore with the latest version and publish again. Deactivating a parent product unpublishes its listings; restoring it does not automatically republish variants.

Upload variant-specific images and choose inherited, replacement, or no images. Updating option labels preserves existing media references; a value used by a variant or media bucket cannot be removed. Connected product-master variants remain managed in BOS.

Recovery, messages and stock alerts

Open Messages to enable cart reminders or stock alerts for this store. Both start disabled. Set the reminder delay and maximum count before enabling recovery. Customers explicitly opt in; guest email addresses must be verified through a signed link. Marketing consent is separate from order service messages.

Recovery links open a reviewed cart using current prices and availability. Purchase, withdrawal, account deletion, expiry or disabling the store feature suppresses further reminders. A stock alert watches the selected variant and requested quantity and sends once when that quantity becomes available.

The message list shows masked recipients, outcomes and attempt history. Accepted means the configured mail transport accepted the message; it does not prove inbox delivery. For a failed or uncertain outcome, confirm with the transport that the message was not accepted before selecting Retry. Do not retry an unknown send without that confirmation. Orders and payments remain accessible when email fails.

Recovery history links to recovered orders. Revenue is grouped by currency and includes paid order totals, including tax and shipping, less successful refunds. It is attribution from a resumed cart, not evidence that the reminder caused a sale.

Steps — shopper-facing recovery

Symptom	Operator check
Store 404 / wrong host	Domains and DNS under General; correct storefront URL
Empty catalog	Listings published? Connected sync / BOS items?
Checkout blocked	Shipping zones/methods; payment methods enabled; stock / out-of-stock policy
Paid but not fulfilled	Orders detail + fulfillment policy; COD collect/release flows
Price/stock mismatch (connected)	BlueMatrix sync / catalog sync; listing price overrides permissions

Result

Shoppers can complete checkout; operators clear the fulfillment queue; connected orders stay aligned with BlueMatrix sales/inventory paths.

Hard stops

• Draft store → no public shopping.
• No payment or shipping method → checkout cannot complete.
• Connected permission gaps (e.g. cannot publish) → listing stays draft online.
• Do not confuse BOS sales invoice screens with storefront checkout — web orders enter via Commerce, then sync to BlueMatrix when connected.

Related

• Merchant dashboard
• Commerce index
• Custom and headless storefronts
• Commerce storefront administration

Standalone promotions

Owners can open Promotions to create draft, active, paused or expired offers. Choose a coupon or automatic trigger, percentage, fixed amount or free shipping, and an explicit combination rule. Enter schedule times in the named IANA time zone. Active coupons appear in checkout automatically. Preview a quote before submission.

Products and collections are alternative item eligibility matches; empty selections include all items. Customer restrictions and per-customer limits require verified sign-in. Minimum spend uses original eligible prices before tax and promotions. Coupons run first, then automatic offers by descending priority and rule ID. Exclusive offers cannot combine. Stackable offers discount the remaining amount, with exact currency allocations; at most ten offers apply to a quote.

Checkout rechecks prices and usage under the store lock. Unpaid orders reserve redemptions until their stock reservation expires. The first payment, including a partial COD collection, consumes usage once. Cancellation and expiry release only unused reservations; refunds do not restore consumed usage. Partial COD keeps its funded stock hold through expiry. A late payment whose redemption has been taken by another order remains financially recorded and requires reconciliation or refund before fulfillment. Connected store controls and invoice-based consumption are described below.

Connected promotion reservations

BOS-published item promotions and coupons remain authoritative for connected prices. Checkout reserves every applied offer, including stacked offers, against the existing BOS usage limits. Limits include other unexpired checkout holds. Empty approval objects cannot bypass revalidation, and a changed rule prevents order creation.

Posting the connected invoice consumes each offer and coupon once. For COD with an invoice at dispatch, consumption occurs at dispatch; with invoice on collection, it occurs with collection. Unused holds release on expiry or cancellation. Already consumed uses remain consumed after refunds. Pausing an offer does not invalidate an unexpired accepted hold. A late invoice whose quota was reassigned fails before stock and accounting posting and requires review of the recorded payment.

An offer or coupon with order history cannot be deleted; pause it instead.

Connected staff with Commerce management and promotion management permissions can open Promotions for the selected store. Create coupon or automatic offers with percentage, fixed-cart or free-shipping discounts, schedules in the selected time zone, product/collection/customer eligibility, minimum spend/quantity and total or per-customer limits. Customer restrictions require verified sign-in. Saving rechecks current staff access in BOS. A stale edit must be reloaded before saving; retrying the same creation operation returns the original offer.

Store coupons run first, then automatic store offers by priority. Exclusive offers replace other discounts across the cart; stackable offers reduce the remaining BOS price. BOS minimum sale prices still apply. Delivery is selected before the final coupon quote, and free shipping reduces its taxable amount to zero. A store offer cannot be edited through the general BOS promotion screen. Existing BOS publication and stacking settings continue to govern ordinary item offers. Comprehensive journey validation remains outstanding.