mPorts
简体中文

Part of mPorts OMS

Don’t discover the problem after you submit.

Product Launch in mPorts OMS gets products ready for a sales channel: you choose the destination, pick the retailer’s category, map your product data to what the retailer requires, validate every product, submit through mPorts connectivity to the channels that are connected, and see what happened. Before you submit, one readiness verdict brings forward the missing mappings, the incomplete product data, the category requirements and the validation failures — grouped, so a blocker affecting many products is fixed once instead of product by product.

See product launch Talk to mPorts

Every retailer wants your product described its way

The same product needs a different category, different required fields and different rules for each place you sell. Doing that in each retailer’s portal means re-entering the product every time, and finding out what was missing only after the rejection comes back — then correcting forty products one at a time.

mPorts OMS does the preparation once, against the retailer’s own requirements, and brings forward what is blocking a launch before you submit it: which fields have no mapping, which products are missing a value, which category rule is unmet, which validation failed — and which of those affect many products at once. It is the same idea as everywhere else in mPorts: find what needs attention before the operator has to hunt for it.

It also meets retailers where they are. Some take a marketplace import through an API; some hand you a spreadsheet template with hundreds of columns and a portal to upload it to; some trade over EDI; some want a person to approve each step. mPorts prepares the same product data for each of those, and does not stop when the listing goes live: the product that launches is the record that takes orders, holds inventory, ships and shows up in cost.

From your product data to a launched product

The work, in the order it happens. Each step is a check you can see; nothing is submitted until the checks that matter are green.

  1. Your product data

  2. Choose the destination

  3. Pick the retailer category

  4. Map required fields

  5. See what is missing

  6. Validate

  7. Submit

  8. See what happened

Rejections come back with why, impact and fix

One readiness verdict per launch

The launch workspace shows eight checks. Each is ready, needs attention, required, not evaluated or not needed — and a check that could not run says “Not evaluated”, never “Ready”.

Product Launch / Launch Products / Spring lighting — Mirakl

Launch readiness

Prepare products for a channel, fix what’s blocking them, and submit

  • DestinationReady
  • Retailer categoryReady
  • Category rulesReady
  • ProductsReady
  • Product data mappingNeeds attention
  • Product dataNeeds attention
  • ValidationNot evaluated
  • SubmissionRequired
The launch readiness panel: the product’s eight checks and the state of each.

One blocked launch, worked end to end

Example

Forty products are being launched to a retailer’s marketplace and the workspace shows “Needs attention”.

  1. Signal

    The readiness panel shows Product data mapping and Product data as “Needs attention”; Validation is “Not evaluated” because it cannot run yet.

  2. What mPorts shows

    “Issues affecting multiple products”: two required retailer fields have no mapping, and twelve products are missing a value for one of them.

  3. Action

    The operator maps the two fields once and fills the twelve values on the products. Validation runs and turns green.

  4. Submit

    The launch is submitted through mPorts connectivity to the connected marketplace.

  5. Record

    Submission history records the run with its accepted and rejected counts; any rejection carries why, impact and fix, and failed rows can be resubmitted.

Example; the counts are illustrative.

  • Launch workspaces

    Prepare a set of products for one destination, fix what is blocking them, and submit.

  • Retailer category and rules

    Pick the retailer’s own category; its required fields and rules follow.

  • Field mapping

    Map your product data to the retailer’s required fields once, per channel and category.

  • Validation

    Every product checked against the requirements, with issues grouped so one fix clears many products.

  • Submission and history

    Submit to the connected channel; every run recorded with accepted, rejected and error counts.

  • Plain-language guidance

    A rejection comes back with why it happened, what it affects and how to fix it.

  • Retailer spreadsheet automation

    Upload the retailer’s own template and its rules become your checks; fill it from your data and download it for the retailer portal — for Home Depot IDM, the original workbook with macros preserved.

  • Bulk onboarding

    Launch a chosen set of products or a whole catalog to a new channel; match rows by SKU, product ID or UPC and review before anything is written.

From product file to live channel.

One product. Different retailer requirements. mPorts turns your product information into the shape each channel expects — a marketplace import, a retailer’s own workbook, a connected channel, a spreadsheet — then carries the operation forward after launch.

Your product data

  • One record per item
  • Attributes, images, variants, cost
  • Imported from your own spreadsheets

mPorts OMS · Product launch

Retailer category, required fields, allowed values and rules — mapped once, validated per product, grouped when one issue blocks many.

  • Marketplace import Submitted through mPorts connectivity — Mirakl-run marketplaces end to end today.
  • Retailer workbook The retailer’s own template, filled from your data; for Home Depot IDM, the original workbook with macros preserved.
  • Spreadsheet or CSV Export the validated launch for a portal or a buyer.
  • Connected channel Other destinations set up per account through mPorts connectivity.

Live

Submission tracked until the channel answers; rejections return with why, impact and fix; failed rows resubmitted.

Then the operation continues

  • Orders
  • Inventory
  • Fulfillment
  • Shipping
  • Exceptions
  • Business analytics
  • AI operations

Commerce still runs on APIs, EDI, marketplace platforms, retailer portals and spreadsheets. mPorts prepares the same product data for each, then keeps working once the product is live.

Which channels can a launch be submitted to?

Submission runs through mPorts connectivity to the channels that are connected for your account. Marketplaces run on Mirakl are connected end to end today; other destinations are set up during onboarding, and we will tell you plainly which ones are ready for your account.

What “readiness” means before a retailer accepts it

A readiness verdict in mPorts checks your own data and mappings. Retailers also set requirements of their own — attributes, images, identifiers, category mapping and, for some categories, compliance documentation — before an item can go live.

What is catalog readiness, and what do retailers require?

Questions buyers ask

How does Product Launch fit with the rest of mPorts OMS?

It is part of mPorts OMS. The products it prepares are the same records your orders, inventory and reports run on, so a product launched to a channel is the product that later takes orders and shows in stock age and cost.

Can mPorts fill a retailer’s Excel template for us?

Yes. Upload the retailer’s own product template workbook and mPorts turns its required fields, categories and allowed values into the rules the launch is checked against. Fill the launch from your product data — matching rows by SKU, product ID or UPC, reviewing before anything is written — then export it as CSV or Excel, or for Home Depot IDM as the retailer’s original workbook with its macros intact, ready to upload to the portal.

Which channels does a launch go to through the API?

Marketplaces run on Mirakl are connected end to end today: the import is submitted through mPorts connectivity and tracked until the channel answers, and failed rows can be resubmitted. Other destinations are set up per account during onboarding. Where a retailer works from a portal and a spreadsheet, that is the format mPorts prepares.

How is “readiness” decided?

By the product, on every read, from the actual state of the launch: is the destination configured, is the retailer category chosen, do enough mappings exist, is the product data complete, did validation run, can it be submitted.

How do I find out why a launch is blocked?

In the launch workspace: the readiness verdict names the check that is not ready, the issues affecting multiple products are grouped, and each rejection comes back with why it happened, what it affects and how to fix it. The AI assistant works on orders, inventory and cost today; launch readiness is a screen you open.

Related reading

Get the next launch ready before you submit it.

Tell us which retailers you are launching to and where the rejections come back today.

Show us your operation See products & catalog