Skip to main content
Order group records live in the Seller module, so you read and write them through the Seller module service. Use it in subscribers, scheduled jobs, and custom steps when you need group rows without child orders. For child orders and their statuses, use the read workflows instead.

​
Resolve the service

Resolve the Seller module from the Medusa container with MercurModules.SELLER. There is no ORDER_GROUP module key.
The call returns the customer’s 20 newest groups and the total number of groups that match.

​
Read methods

The Seller module overrides the generated read methods for OrderGroup. All three run one SQL query through OrderGroupRepository, which fills seller_count and total: From config, the repository reads take, skip, and order only. It ignores select and relations and always returns every column plus the two computed fields.
retrieveOrderGroup doesn’t throw when no group has the id: it resolves to undefined. Check the value before you use it, or use getOrderGroupDetailWorkflow, which throws NOT_FOUND.

​
Write methods

The write methods are the ones MedusaService generates for the model: Creating a group doesn’t create orders or links. Checkout does that in completeCartWithSplitOrdersWorkflow, so prefer the workflow over calling createOrderGroups yourself.

​
Filters and sorting

The repository builds its own SQL and reads only the top-level keys below. It ignores every other key, including $and and $or. The order-level filters only choose which groups match. seller_count and total still cover every order in each matching group. Pass id as a plain string or array: an { $in: [...] } map isn’t read. config.order sorts by display_id, created_at, or updated_at, with ASC or DESC. Other keys are ignored. Without a valid key, groups come back by created_at descending.