Shop
Shop data & automation
Namespaces, workflow events, reporting surfaces, and API reference links for Shop.
JQL Namespaces
The primary namespaces follow the module models in src/shopbyantly/models.py. Use /reference/shopbyantly for the curated namespace reference, supported intents, fields, filters, permissions, and examples.
| Namespace | Use it for |
|---|---|
shopbyantly.Shop | Merchant shop profile, alias, domain, currency, store connection, and status. |
shopbyantly.ProductListing, shopbyantly.ProductListingVariant | Public product listing and shop-specific variant data. |
shopbyantly.Cart, shopbyantly.CartItem | Shopper cart state and selected items. |
shopbyantly.ShippingRate | Delivery pricing and availability. |
shopbyantly.CheckoutSession | Checkout lifecycle and validation. |
shopbyantly.ShopPayment, shopbyantly.ShopTransaction | Payment and transaction records for storefront orders. |
Useful Workflow Events
Prefer explicit automation event constants where the backend defines them. Where a module has no dedicated event class yet, model workflows around create, update, status, assignment, approval, publish, post, and archive transitions on the namespaces above.
shopbyantly.Shop:createshopbyantly.Shop:activateshopbyantly.Shop:suspendshopbyantly.ProductListing:createshopbyantly.ProductListing:updateshopbyantly.ProductListing:publishshopbyantly.Cart:createshopbyantly.CheckoutSession:createshopbyantly.ShopPayment:createshopbyantly.ShopTransaction:create
Create And Update Patterns
- Create events are best for notifications, initial assignment, SLA timers, provisioning, and first-time validation.
- Update events are best for synchronization, report enrichment, downstream recalculation, and integration callbacks.
- Status-change events are best for approvals, escalations, posting, publishing, cancellation, rejection, or completion.
- Assignment events are best for task creation, manager notifications, workload routing, and access review.
- Delete events should be rare; prefer archive, cancel, close, void, suspend, or deactivate when historical reporting matters.
- External integrations should include the module record id, tenant id, owner, status, timestamps, and source system key.
- Workflow filters should narrow by status, type, owner, or amount so routine edits do not trigger noisy automation.
- Scripts should be used for calculations, transformations, and integrations that workflow nodes cannot express cleanly.
Reports And Dashboards
- Shop status and onboarding.
- Published listings and stock availability.
- Carts and abandoned checkout.
- Checkout success and failure.
- Payments and transactions.
- Shipping rate usage.
- Merchant billing.
Automation Recipes
- When a new Shop record is created, notify the owner and create an onboarding or review task if required fields are missing.
- When a record enters a pending approval state, route it to the correct approver and set a due date.
- When a record is approved, update related Base objects, create downstream module records, or notify the requester.
- When a record is rejected, capture reason, notify the requester, and create a correction task if the process can continue.
- When a record is completed or posted, lock downstream assumptions and refresh reporting dimensions.
- When a record is cancelled, voided, archived, or suspended, notify dependent owners and stop open tasks where appropriate.
- When an integration fails, log the source payload key and create a task for the owning operations team.
- When a report shows stale records, trigger a recurring workflow that reminds owners before escalation.
Integration Guardrails
- Use the narrowest API key or integration role that can read and write the required namespaces.
- Do not let integrations bypass approval, posting, payment, fulfillment, or publication actions that users must perform in the UI.
- Use idempotency keys or source-system identifiers for imports and callbacks.
- Validate tenant ownership on every linked record before creating cross-module relationships.
- Avoid free-form status values; use the statuses and actions exposed by the module models and controllers.
- Keep workflow payloads small but include enough context for audit and troubleshooting.
- Test integrations with one complete lifecycle before scheduling bulk imports or recurring jobs.
- Review failed jobs and webhook logs as part of the module operating rhythm.
Reference Link
- Start with /reference/shopbyantly for namespaces, fields, filters, permissions, and intents.
- Pair this page with the setup and working pages so automation follows the same lifecycle users see in the product.
- For cross-module workflows, also review references for objects, tasks, tickets, reports, notifications, and workflow automation.