Working in Shop

Daily Operating Model

Shop works best when teams treat the module record as the source of truth and use tasks, tickets, workflows, and reports as supporting surfaces. The flows below are the common day-to-day paths to validate during setup and train users on after go-live.

Flow 1: Create and activate a shop

1. Start merchant onboarding or open Shops and create a new shop.
2. Enter name, alias, description, currency, logo, and contact details.
3. Attach the inventory store that supplies stock.
4. Configure domain or custom domain when required.
5. Complete general shop settings and storefront policy pages.
6. Activate the shop after content, payment, and shipping checks pass.
7. Open the public shopfront route and confirm branding and catalogue display.
8. Keep draft shops unpublished until checkout is tested.

Flow 2: Publish product listings

1. Open Products or Listings for the shop.
2. Select an inventory product and variant set.
3. Set title, slug, description, price override, images, and publication state.
4. Confirm stock exists in the connected inventory store.
5. Publish the listing and inspect the public product page.
6. Group listings into categories where storefront navigation uses them.
7. Update listings when inventory price or availability changes.
8. Use reports to find unpublished or out-of-stock listings.

Flow 3: Process carts and checkout

1. Customer adds listings to the cart from the shopfront.
2. Cart and CartItem records track selected quantities.
3. Customer moves to checkout and chooses shipping.
4. CheckoutSession validates stock, shipping rate, and payment readiness.
5. Payment creates ShopPayment and ShopTransaction records.
6. Successful checkout creates the downstream order or fulfillment handoff.
7. Failed checkout remains available for support review.
8. Use workflow notifications for abandoned carts or failed payments when configured.

Flow 4: Manage orders, shipping, and exceptions

1. Open merchant orders for the shop alias.
2. Review payment, shipping, customer, and item details.
3. Coordinate fulfillment with inventory stock locations.
4. Update shipping or order status when the package moves.
5. Handle cancellation, refund, or payment exception through permitted actions.
6. Review shop transactions for settlement and reconciliation.
7. Suspend or close shops only through controlled status actions.
8. Use storefront analytics and reports to improve catalogue and checkout performance.

Day-To-Day Controls

• Start from the launchpad route, then use filters and saved views to focus on records needing action.
• Use status fields and lifecycle actions instead of free-text notes for important state changes.
• Attach documents, comments, or related records when a decision needs evidence.
• Create tasks when work leaves the current owner or needs a due date.
• Create tickets when the work is customer-facing or belongs in a support/service queue.
• Use workflows for predictable notifications, approvals, escalations, and cross-module updates.
• Use reports for recurring team reviews rather than exporting ad hoc lists every time.
• Keep permissions tight enough that users see the records they need but not sensitive configuration.
• Review rejected, cancelled, failed, or overdue records every week.
• Keep integrations aligned with the same lifecycle users follow in the UI.

Exception Handling

• If a record is stuck, check owner, status, required fields, approvals, and linked records before editing downstream data.
• If a workflow did not run, confirm the event name, trigger filter, record permissions, and service-user access.
• If reports look wrong, inspect whether the source record is draft, cancelled, archived, or missing a required dimension.
• If an integration created bad data, fix the source mapping and then repair the affected records through supported actions.
• If users cannot see a route, review launchpad access, module roles, page permissions, and tenant feature flags.
• If a public or embedded route exposes too much, disable exposure first and then correct permissions or filters.
• If two modules disagree, choose the module that owns the lifecycle as the source of truth and update the other from it.
• If a record supports audit, void, archive, or cancel it instead of deleting it whenever possible.

Reporting Rhythm

• Daily: review new, overdue, failed, rejected, and pending-approval records.
• Weekly: review owner workload, aging, status changes, and recurring exceptions.
• Monthly: review configuration, permissions, integration failures, and report definitions.
• Quarterly: review whether custom pages, workflows, and API access still match real operating practice.
• After major process changes: rerun one end-to-end flow with a pilot record before enabling it broadly.

Cross-Module Handoffs

• To Base objects: pass stable identifiers, owner, status, dates, and any dimensions required for reports.
• To tasks: include a precise action, due date, source record link, and escalation owner.
• To tickets: include requester, priority, support context, and the module record link.
• To workflows: prefer explicit create, update, approval, and status-change triggers.
• To reports: keep dimensions consistent across records so dashboards can group accurately.
• To integrations: use /reference/shopbyantly for namespace and intent details.