Commerce screens and records

This is the reference for every screen in the Commerce app: what each one holds, what you can do on it, and why many of them have no New, Edit or Delete button. Use it when you are looking for a record, when a button you expect is missing, or when you are deciding who should see which screen.

Overview

As shipped, the Commerce app's navigation lists Commerce Home (a dashboard page) and then the parent records only: Stores, Carts, Checkout Sessions, Orders, Payment Transactions, Coupon Campaigns, Partner Microsites, Reports and Dashboards. The settings records are opened from the App Launcher (see Settings). The app is a web app; it is not in the field app.

The module's records fall into three groups:

Read-only by design

The fifteen service-written 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 catalogue entry because someone published. They are marked as not creatable, editable or deletable 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.

Administrator-authored records: no buttons as shipped

The nine administrator-authored records can be created, changed and deleted: the platform allows it and your security profile decides who may. But none of them ships with New, Edit or Delete actions, and a screen only shows a button for an action the record has. So on the shipped screens:

• the lists for channels, gateway accounts, webhook subscriptions, coupon campaigns, microsites and partner targets have no New button;
• their record pages show no Edit or Delete in the header, and fields cannot be changed in place;
• the child tabs show no New: Codes on a coupon campaign, Service Areas on a microsite, Tier Ladder on a partner target, and the related lists of channels and microsites on a channel or gateway account. The same goes for Partner Service Areas on a Partner Store link.

The record pages are already laid out for these buttons: the headers name Edit and Delete, and the child tabs name New. They appear as soon as the record has actions with those names. Until then, use one of these routes.

Some records have their own administrator endpoints that do more than a plain create: provisioning a microsite also creates its channel, and publishing a microsite checks the catalogue first. See Partner microsites and order routing.

Storefront

On the shipped store record, the Related tab lists its Store Categories (the browse tree — categories nest, and Show in Catalog decides which categories the catalogue offers as filters; products in the others still appear under All). Categories are authored here; see Stores. The store's Partner Store links (which partners resolve to this store), Catalog Publications, Catalog Slugs and Commerce Channels are not on the shipped store record: open them from their own lists, for example /PartnerStore or /CatalogPublication, or add them to the store layout in the Design Studio. Publications and slugs are produced by publishing. Partner Store links are explained in Catalogue and pricing.

A Catalog Publication is one 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 address of a listing or category, assigned once per store and never reused.

Selling

Cart Status:

• Active — the shopper can still change it.
• Abandoned — idle past the abandonment window (four hours by default). From this point the basket refuses every change; nothing turns it back to Active.
• Ordered — converted into an order.
• Merged — folded into another basket when the shopper signed in.
• Expired — past the cart lifetime (72 hours by default); final.

Checkout session Status answers "the money left but there is no order":

• Open — addresses captured, nothing frozen yet.
• Awaiting Payment — the prices are locked and the stock and coupon holds are taken. The cart cannot be changed while a session is in this state.
• Paid — the payment was captured but placement has not run yet. This is a timing state the recovery job resolves, not a lost order.
• Placed — the order exists.
• Failed — see Failure Code below.
• Expired — the shopper cancelled the checkout and its holds were released. A session whose holds simply timed out keeps its last status; the holds are still released.

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 prices and quantities are frozen before the gateway is asked for money. Details: Direct-to-consumer selling.

Payments

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 or Failed) follows from it. Captured and Failed are final: a later refund is recorded as an event, but the status stays Captured, so Refunded and Partially Refunded are not reached in practice (see Payments and gateways). 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, gateway accounts and coupon redemptions are audited.

Promotions

Watch Budget Spent and Is Overspent while a campaign runs. The budget cap never refuses a shopper: an order that takes the campaign past its cap completes with the discount and the campaign is flagged Is Overspent, so nobody is rejected for arithmetic they cannot see. Codes keep redeeming after that — to stop the campaign, change its Status to Paused or Ended. Only an Active campaign inside its start and end dates accepts codes; codes are matched without regard to letter case. Redemptions and reservations beneath a campaign are service-written.

Partners

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. Settlements accrue once a day. To accrue straight away, go to Setup → Platform → Monitoring → Jobs, create a schedule for Accrue partner microsite settlements on the Schedules tab and use Run now on it (see Background work). It is safe to run alongside the daily pass. Nothing in xMatix moves a settlement to Statemented or Settled. See Partner microsites and order routing.

On a tenant set up as a single company, the partner screens — microsites, service areas, settlements, targets and their tiers, and Partner Store links — are hidden.

Settings

The shipped navigation has no Settings entry; Commerce Home took its place. A shipped Settings page of tiles still exists, and an administrator can add it back as a page entry of the Commerce app under Setup → Design Studio → Apps. Until then, type the record's name (for example Commerce Channel) in the App Launcher search to open its list. The settings records are:

• Commerce Channels — one per selling surface. A channel's Related tab lists its webhook subscriptions, coupon campaigns, microsites, carts and checkout sessions.
• Payment Gateway Accounts — secret-store references, never secrets. The Related tab lists the channels that use the account and its payment transactions. See Payments and gateways.
• Webhook Subscriptions — for headless consumers.
• Partner Settlements and Partner Targets — the two periodic partner back-office lists, kept out of the top navigation because they are worked in bursts across all partners at once.

A webhook subscription's Deliveries tab shows each event sent to it, with Status (Pending, Delivered or Failed), Attempts, Last Status Code and Last Error. A delivery that fails is retried after 1, 2, 4, 8, 16 and 32 minutes and then hourly; after its eighth attempt it is marked Failed and kept, so you can always answer "did you send it?". The subscription counts Consecutive Failures across all its deliveries, and a successful delivery resets the count. At 50 consecutive failures the subscription's Is Active is switched off and no more events are queued for it; its Last Failure Message shows the last error.

The timing settings for carts, checkout and reconciliation (the 72-hour cart lifetime and four-hour abandonment window among them) are under Setup → Feature Hub → Commerce → Settings; see Direct-to-consumer selling.

Why line-level records are not in the navigation

Cart lines, catalogue 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 record page, the way order lines are reached from an order. Opened on its own, a line table shows rows with no parent context — and for the service-written ones, rows you could not act on anyway.

Training

Practice exercise

In a sandbox with the Commerce product:

1. Open Carts from the Commerce app and open any cart. Note its Status, then open its Lines tab and its Related tab. Expected result: no New, Edit or Delete button anywhere, and the Related tab lists the checkout sessions started from the cart.
2. Open Coupon Campaigns and confirm that the list has no New button. Add ?create=1 to the address and create a Draft campaign with Benefit Type Percent. Expected result: the campaign is saved and appears in the list; when you open it, its record page has a Codes tab and no Edit button.
3. Open Payment Transactions, open a captured transaction and read its Events tab from top to bottom. Expected result: you can name the event that set the status to Captured.

Quick reference

• Service-written screens (carts, checkout sessions, payments, publications, settlements) are read-only by design.
• Administrator-authored records have no New, Edit or Delete buttons until an administrator adds the actions.
• Create one without the button: add ?create=1 to the list address.
• Settings records open from the App Launcher; there is no Settings entry in the shipped navigation.
• An Abandoned cart cannot be changed again.
• A refund never moves a payment off Captured; read the Events tab.
• The coupon budget cap flags Is Overspent but never stops redemptions — pause the campaign.
• A webhook subscription switches itself off after 50 consecutive failed deliveries.

Permissions

App and entity access are strict allow-lists with no administrator bypass. As shipped, three profiles see the Commerce app:

Write access on an administrator-authored record matters for the ?create=1 form, the Setup Copilot and the Data API; it does not add buttons to the shipped screens. Once an administrator adds New, Edit and Delete actions, each button follows the same profile access. Widen access under security profiles by granting the app and then read on the records it navigates to — the app without the record access is a visible tile over an empty menu.

Configuration

Add New, Edit and Delete to an administrator-authored record

1. Go to Setup → Design Studio → Entities and open the record — for example Coupon Campaign.
2. Open its Actions page and add the actions the shipped screens already have places for: New (for the list and for the child tabs on its parent's page), Edit and Delete (for the record page header). The names must be exactly New, Edit and Delete, because the shipped pages find their buttons by name.
3. Repeat for each child record whose tab needs a New button — Coupon Code, Partner Service Area, Partner Target Tier.
4. Reload the Commerce screens. The buttons appear for users whose profile allows the matching access.

Microsite provisioning and microsite publishing are better done through their administrator endpoints than through a plain New or a Status change; see Partner microsites and order routing.

Other settings that change these screens

Common problems

The list has no New button

If the record is service-written (carts, checkout sessions, payments, publications, settlements, deliveries), it cannot be created by hand at all. If it is administrator-authored (channels, gateway accounts, webhook subscriptions, coupon campaigns, microsites, partner targets), the action is missing as shipped: add ?create=1 to the list address, or ask an administrator to add the actions.

I can open a coupon campaign or channel but cannot change it

There is no Edit action on these records as shipped, so the fields are read-only on the page whatever your profile allows. Make the change through the Setup Copilot or the Data API, or have an administrator add Edit and Delete actions.

A shopper's basket cannot be changed

Check the cart's Status. Only an Active cart accepts changes; Abandoned, Expired, Merged and Ordered carts refuse them. An Active cart is also locked while one of its checkout sessions is Awaiting Payment — cancelling that checkout unlocks it.

Our webhook consumer stopped receiving events

Open the subscription from Webhook Subscriptions and check Is Active, Consecutive Failures and Last Failure Message. After 50 consecutive failed deliveries the subscription switches itself off. Fix the endpoint first, then turn the subscription back on through the Commerce administration endpoint for re-enabling a webhook, which also resets the failure count.

A partner's settlement is missing this month's orders

Settlements accrue once a day. To accrue now, use Run now on a schedule for Accrue partner microsite settlements under Setup → Platform → Monitoring → Jobs, then reopen the settlement. Orders with a total of zero or less, deleted orders and microsites with no settlement percent are never accrued.

Common questions

Why can I see these records but not edit them?

Two different reasons. Carts, checkout sessions, payments, catalogue builds, reservations, deliveries and settlements are produced by the pricing, checkout, publishing, dispatch and accrual services, so the platform keeps them read-only: editing one by hand would produce a record no engine agreed to. Channels, gateway accounts, webhook subscriptions, coupon campaigns, microsites and partner targets can be changed, but their shipped screens have no Edit action — use the Setup Copilot or the Data API, or have an administrator add the actions.

Where do I find a cart's lines, or a payment's events?

On the record's own page. Every Commerce record page puts the primary child collection first — a cart's Lines, a payment's Events, a campaign's Codes, a microsite's Service Areas, a settlement's Lines — then, where there is one, a Related tab with the other connected records, then Details with the fields.

A product is in the item master but not on the storefront. Where do I look?

At the store's Live catalogue publication, on its Entries tab. If the product is not there, it was not published. Content, prices and stock labels on the storefront's browse pages all change only when the store is published again; the cart and checkout always price against current rules.

Where are the Publish, Refund and Run Settlement buttons?

There are none on any record. 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 settlement accrual can also be started with Run now on the Jobs screen; refunds are issued at the payment provider and recorded here from its webhook. See Payments and gateways.

Related topics

• xMatix Commerce
• Direct-to-consumer selling
• Payments and gateways
• Partner microsites and order routing
• Catalogue and pricing
• Stores
• Security profiles