This is the reference for what each screen in the Commerce app holds, what you can do on it, and — the question that comes up most — why some of them have no New button. The app's navigation lists parent records only: Stores, Carts, Checkout Sessions, Orders, Payment Transactions, Coupon Campaigns, Partner Microsites, Reports, Dashboards and Settings.
Read-only by design
Fifteen of the module's records are written only by the services that own them: a cart line exists because a pricing pass created it, a payment event because a gateway said something, a catalog entry because someone published. Those entities are flagged non-creatable and non-editable in the platform metadata, so every screen for them is readable, filterable, exportable and reportable but never editable — the New button is absent rather than present-and-failing, and the Data API refuses to create them. Nine records are administrator-authored: commerce channels, payment gateway accounts, webhook subscriptions, coupon campaigns and their codes, partner microsites and their service areas, and partner targets with their tiers.
One honest gap on the authored side: today the lists for channels, gateway accounts, coupon campaigns and microsites carry no New button either, because no list actions are seeded for them. Records are created through the Setup Copilot or the Data API, or by opening the list's create form directly (/<entity>?create=1), and are editable once they exist.
Storefront
| Screen | What it holds | Editable |
|---|---|---|
| Stores | A retail outlet or sales location — the range a channel sells from. Name, label, description, currency, an optional partner account or partner account group, and an external id. | Yes |
Everything else about a store is on its record. The Related tab lists its Store Categories (the browse tree — categories nest, and Show in Catalog decides whether buyers see one), its Partner Store links (which dealers resolve to this store), its Catalog Publications, Catalog Slugs and Commerce Channels. Categories are authored here; publications and slugs are produced by publishing.
A Catalog Publication is one immutable, versioned build of the store's range with status Building, Live, Superseded or Failed. Exactly one is Live per store; the last two superseded versions stay resolvable; a Failed build keeps its error message and leaves the previous version live. Its Entries are precisely what shoppers can see — when a product is on the item master but missing from the storefront, absent there means unpublished, and the fix is to publish again rather than to edit the item. A Catalog Slug is the permanent public URL of a listing or category, assigned once per store and never reused.
Selling
| Screen | What it holds | Editable |
|---|---|---|
| Carts | A shopper's basket for one channel, signed in or anonymous — status, totals, applied coupon, addresses, and when it was last priced. Its Lines tab is the contents. | No |
| Checkout Sessions | One attempt to turn a cart into an order and the record of where it stopped. Its Related tab carries the payment attempts and the stock and coupon holds taken for it. | No |
| Orders | The ordinary sales order a converted cart becomes — the same document a dealer, a field rep or the back office produces. | Yes |
Cart Status: Active is live; Abandoned is idle past the window (four hours by default) and still recoverable; Ordered converted; Merged was folded into another basket at sign-in; Expired (72 hours by default) is terminal.
Checkout Status answers "the money left but there is no order": Open (addresses captured, nothing frozen), Awaiting Payment (snapshot locked, holds taken), Paid (captured; placement has not run yet — a timing state the recovery job resolves, not a lost order), Placed, Failed or Expired. Every Failure Code — CART_EMPTY, PRICE_CHANGED, OUT_OF_STOCK, COUPON_EXHAUSTED, PAYMENT_FAILED, ADDRESS_INVALID, DELIVERY_SLOT_UNAVAILABLE — is a pre-payment outcome, because the commercial snapshot is frozen before the gateway is asked for money.
Payments
| Screen | What it holds | Editable |
|---|---|---|
| Payment Transactions | One payment attempt — a retry produces a second row, distinguished by attempt number and idempotency key. Gateway, method, amount, status, refunded amount and the gateway's own ids. | No |
The Events tab is the append-only trail written from the gateway's signed callbacks and the recovery job — initiated, intent created, redirected, webhook received, signature verified or rejected, authorized, captured, failed, reconciled, refund requested, refunded — and the transaction's status (Created, Authorized, Captured, Failed, Refunded, Partially Refunded) is a projection of it. Failure Category buckets a failure into declined, gateway error, timeout, signature invalid, user abandoned or unknown. A transaction sitting at Created with no further events is an abandoned redirect, which the reconciliation pass resolves. Payment transactions, their events and gateway accounts are audited.
Promotions
| Screen | What it holds | Editable |
|---|---|---|
| Coupon Campaigns | The offer — status (Draft, Active, Paused, Ended), benefit type (percent with a cap, amount, or scheme delegating to a trade scheme), window, minimum cart value, channel and account-group scope, first-order-only, per-customer and total caps, stacking policy (exclusive or stackable) and budget. Its Codes tab holds the redeemable codes. | Yes |
Watch Budget Spent and Is Overspent while a campaign runs. Crossing the cap does not begin refusing shoppers: the order completes and the redemption is flagged, so nobody is rejected for arithmetic they cannot see. Redemptions and reservations beneath a campaign are service-written.
Partners
| Screen | What it holds | Editable |
|---|---|---|
| Partner Microsites | A partner's storefront on its own slug, over the store that partner resolves to — status Draft, Live or Suspended, display name, theme, settlement percent and channel. Its Service Areas tab declares the pincodes it delivers to, with priorities. | Yes |
| Partner Settlements (Settings) | What is owed to a partner for a month — gross, commission, net and order count — moving from Accrued to Statemented to Settled. | No — accrued by a daily job |
| Partner Targets (Settings) | What a partner account is expected to buy in a period, with its tier ladder; achievement is computed live from invoiced or ordered documents. | Yes |
A settlement's Lines tab is the per-order detail, and each line carries the commission percentage the job applied when it accrued that order; lines are never recomputed.
Settings
The Settings item opens a page of tiles rather than a menu. Behind it sit the administrator-authored records — Commerce Channels (one per selling surface), Payment Gateway Accounts (secret-store references, never secrets) and Webhook Subscriptions for headless consumers — plus the two periodic partner back-office lists, Partner Settlements and Partner Targets. They live here rather than in the top navigation because they are worked in bursts across all partners at once. A webhook subscription's Deliveries tab shows each attempt with its status code; deliveries retry with backoff for about a day and a subscription that keeps failing is disabled rather than retried forever.
Why line-level records are not in the navigation
Cart lines, catalog entries and categories, payment events, coupon codes and redemptions, reservations, webhook deliveries, service areas, settlement lines and target tiers have no menu entry. They are reached on their parent's detail page, the way order lines are reached from an order. Opened unscoped, a line table shows rows with no parent context — and for the service-written ones, rows you could not act on anyway.
Who can see the app
App and entity access are strict allow-lists with no administrator bypass. As shipped, the System Admin profile sees the Commerce app and its Settings with full access; the Sales Manager profile sees both with read access, plus write access on the merchandising records (campaigns, codes, microsites, service areas, targets and tiers) but not on channels, gateway accounts or webhooks. Widen it under security profiles by granting the app and then read on the entities it navigates to — the app without the entity rows is a visible tile over an empty menu.
Common questions
Why can I see these records but not edit them?
Because a service owns them. Carts, checkout sessions, payments, catalog projections, reservations, deliveries and settlements are produced by the pricing, checkout, publishing, dispatch and accrual paths. Editing one by hand would produce a record no engine agreed to, so the platform makes the screens readable and leaves the writing to the code that owns the rules.
Where do I find a cart's lines, or a payment's events?
On the record's own page. Every commerce detail page puts the primary child collection first, then a Related tab with the other connected records, then the fields.
A product is in the item master but not on the storefront. Where do I look?
At the store's Live catalog publication, on its Entries tab. If the product is not there, it was not published — prices refresh on their own, but content changes need a publish.
Where are the Publish, Refund and Run Settlement buttons?
There are none on any record today. Publishing a catalogue or a microsite and rotating a headless key are administrator endpoints; settlement accrual, payment recovery, cart expiry and webhook dispatch are scheduled jobs; and refunds are issued at the payment provider and recorded here from its webhook. See Payments and gateways.