Sales

Deal pipelines, point-of-sale configuration and orders, and storefront ecommerce helpers.

Sales provides the deal pipeline (boards → pipelines → stages → deals with labels, checklists, watchers, and per-deal product/payment data), the POS configuration and order API used by the separate posclient plugin, and a small ecommerce module (wishlists, reviews, addresses, last-viewed items) exposed over HTTP routes and GraphQL. It registers with the platform through meta/: permissions, automations, notifications, the sales:sales.deals and sales:pos.orders segment definitions, sales:deal document generation, record references (including excludeLoyaltyAmount), and the deal property type.

sales_api contains the POS configuration and order APIs. posclient_api and the posclient-front app are the separately deployed storefront; they sync through this plugin's /pos-init, /pos-sync-config, and /get-pos-token routes (src/routes.ts) and the pos.createOrUpdateOrders* tRPC procedures (src/trpc/init-trpc.ts).

For the product catalog itself, see Products; for the deployed POS storefront, see POS Client.

Enabling and ports

ENABLED_PLUGINS=sales

The entry maps to sales_api and sales_ui; dev scripts append _api/_ui to each name in ENABLED_PLUGINS.

ProjectRoleDev port
sales_apiFederated GraphQL subgraph + tRPC + POS/ecommerce HTTP routes; subscriptions enabled3305
sales_uiModule Federation remote3005

The API port is set in main.ts.

The POS storefront backend (posclient_api, port 3312) and app (apps/posclient-front, dev port 7002) are separate; see Point of Sale and POS Client.

Module map

ModuleWhat it containsKey collectionsGuide
modules/sales/Boards, pipelines, stages, deals, labels, checklists; segment fields, documents, referencesDeals, Pipelines, Stages, BoardsDeals & Pipelines
modules/pos/POS configs, orders, covers, slots, product groups; POS sync routesPos, PosOrders, PosCovers, PosSlotsPoint of Sale
modules/ecommerce/Wishlists, product reviews, addresses, last-viewed itemsWishlist, ProductReview, Address, LastViewedItemEcommerce
meta/permissions, automations, notifications, segments, documents, references, properties, beforeResolvers, afterProcessplatform extension pointsthis page and module pages

Frontend sales_ui modules mirror this: deals/ (boards, pipelines, deal detail, product/payment data), payments/, pos/ (POS settings under settings/sales/*). src/config.tsx registers sales/deals, sales/pos, and settings/sales/* navigation.

How it connects to Core

  • Properties: meta/properties.ts declares the deal property type with its systemFields; pipeline propertyIds are validated against Core sales:deal fields over tRPC (fields.find).
  • Segments: meta/segments.ts merges the sales and pos module definitions: sales:sales.deals and sales:pos.orders content types, customer.deals/company.deals relations backed by Core relation records, plus evaluateFields, listSegmentMembers, countSegmentMembers, and applyMembership producers. See Properties, Tags & Segments.
  • Automations: meta/automations.ts registers deal triggers/actions and the POS-order event trigger; see Automations & Approvals.
  • Documents: meta/documents.ts registers sales:deal for document templates; documents.editorAttributes and deal.replaceContent tRPC procedures provide the editor merge fields. See Documents.
  • Payments: meta.payments callbacks apply paid transactions to mobileAmount/mobileAmounts on deals and forward POS-order payments to posclient over tRPC. Payment providers are part of the Enterprise Edition.
  • Import/export: one export type, sales:pos.posItems, gated by posItemsExportManage.

Configuration

Env vars the plugin reads directly:

VariablePurpose
GET_CP_TOKENShared secret for GET /get-pos-token, which lists POS names and tokens for the client-portal flow
ALLOW_OFFLINE_POSWhen truthy, lets pos.create keep onServer unset (offline-capable POS); otherwise new POS docs are forced onServer
DOMAINBase URL used to build deal/board links ({DOMAIN}/deal/board?...)
TIMEZONE, NODE_ENVTimezone for date handling; production flag for the subscription bundle

POS credentials live on the POS document itself (token, adminIds, cashierIds, paymentIds).

Pages in this section

Was this helpful?